WT should start up fast: profile the startup path and trim anything that takes a while #8143

@ghost commented on GitHub (May 14, 2020):

and the Terminal needs to stand up a XAML stack

XAML stack means UWP?

@ghost commented on GitHub (May 14, 2020): > and the Terminal needs to stand up a XAML stack XAML stack means UWP?

claunia commented

@mdtauk commented on GitHub (May 14, 2020):

and the Terminal needs to stand up a XAML stack

XAML stack means UWP?

This uses a Xaml Island for now, but with WinUI 3.0 Xaml will not be tied to UWP, and can be used with Win32 code

@mdtauk commented on GitHub (May 14, 2020): > > and the Terminal needs to stand up a XAML stack > > XAML stack means UWP? This uses a Xaml Island for now, but with WinUI 3.0 Xaml will not be tied to UWP, and can be used with Win32 code

claunia commented

@zadjii-msft commented on GitHub (May 14, 2020):

To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (typically) run as a packaged application.

The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies.

@zadjii-msft commented on GitHub (May 14, 2020): To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (_typically_) run as a packaged application. The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies.

claunia commented

@AnuthaDev commented on GitHub (May 14, 2020):

@zadjii-msft Would it be possible to eliminate the XAML stack entirely from the equation? Using a combination of directx/directcomposition/win32 technologies to create the UI. I mean, terminal really doesn't "require" XAML, most of its UI is pretty straightforward, and should be pretty easy to do in c++. The most important part I believe is the TermControl that is needed for a minimum viable product. Have you investigated this scenario/ is there interest in it. I would love to help to make this happen. But I understand that would require significant resources, and currently, optimizing XAML is the best bet.

@AnuthaDev commented on GitHub (May 14, 2020): @zadjii-msft Would it be possible to eliminate the XAML stack entirely from the equation? Using a combination of directx/directcomposition/win32 technologies to create the UI. I mean, terminal really doesn't "require" XAML, most of its UI is pretty straightforward, and should be pretty easy to do in c++. The most important part I believe is the TermControl that is needed for a minimum viable product. Have you investigated this scenario/ is there interest in it. I would love to help to make this happen. But I understand that would require significant resources, and currently, optimizing XAML is the best bet.

claunia commented

@zadjii-msft commented on GitHub (May 14, 2020):

I mean, that's a possibility, sure, but I think as the Terminal UI gets more elaborate, using DComp for the entire UI is going to be less and less feasible. Plus, if we do want 3rd party developers writing extensions to provide their own UI elements for the Terminal (see #4000), it'd probably be more developer-friendly to ask them to write XAML components rather than DComp visuals

@zadjii-msft commented on GitHub (May 14, 2020): I mean, that's a _possibility_, sure, but I think as the Terminal UI gets more elaborate, using DComp for the entire UI is going to be less and less feasible. Plus, if we do want 3rd party developers writing extensions to provide their own UI elements for the Terminal (see #4000), it'd probably be more developer-friendly to ask them to write XAML components rather than DComp visuals

claunia commented

@ghost commented on GitHub (May 14, 2020):

To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (typically) run as a packaged application.

The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies.

It looks and feels like a UWP app though. Maybe that's the problem.

@ghost commented on GitHub (May 14, 2020): > To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (_typically_) run as a packaged application. > > The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies. It looks and feels like a UWP app though. Maybe that's the problem.

claunia commented

@mdtauk commented on GitHub (May 14, 2020):

@zadjii-msft Would it be possible to eliminate the XAML stack entirely from the equation? Using a combination of directx/directcomposition/win32 technologies to create the UI. I mean, terminal really doesn't "require" XAML, most of its UI is pretty straightforward, and should be pretty easy to do in c++. The most important part I believe is the TermControl that is needed for a minimum viable product. Have you investigated this scenario/ is there interest in it. I would love to help to make this happen. But I understand that would require significant resources, and currently, optimizing XAML is the best bet.

Part of the idea for this project is to modernise the terminal UI and feature set, supporting multiple console types, and show the best of Windows.

Choosing not to implement the modern UI stack, is not within that scope. Windows 10X's shell has moved to XAML, and XAML is being decoupled from the OS and being open sourced, so the community can push it forward, without relying on new OS updates.

By the end of the year, all the code should be in the GitHub, and then the community can explore how to improve performance.

The app is using C++ and so is XAML. Being able to move out of the use of an Island will possibly bring with it some perf benefits by default

@mdtauk commented on GitHub (May 14, 2020): > @zadjii-msft Would it be possible to eliminate the XAML stack entirely from the equation? Using a combination of directx/directcomposition/win32 technologies to create the UI. I mean, terminal really doesn't "require" XAML, most of its UI is pretty straightforward, and should be pretty easy to do in c++. The most important part I believe is the TermControl that is needed for a minimum viable product. Have you investigated this scenario/ is there interest in it. I would love to help to make this happen. But I understand that would require significant resources, and currently, optimizing XAML is the best bet. Part of the idea for this project is to modernise the terminal UI and feature set, supporting multiple console types, and show the best of Windows. Choosing not to implement the modern UI stack, is not within that scope. Windows 10X's shell has moved to XAML, and XAML is being decoupled from the OS and being open sourced, so the community can push it forward, without relying on new OS updates. By the end of the year, all the code should be in the GitHub, and then the community can explore how to improve performance. The app is using C++ and so is XAML. Being able to move out of the use of an Island will possibly bring with it some perf benefits by default

claunia commented

@mdtauk commented on GitHub (May 14, 2020):

To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (typically) run as a packaged application.
The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies.

It looks and feels like a UWP app though. Maybe that's the problem.

It is the direction Windows is moving in, so its not like it looks like UWP, but Windows is moving towards that UI everywhere.

@mdtauk commented on GitHub (May 14, 2020): > > To be technically correct - the Terminal is a Win32 application that's using Xaml Islands to host UWP XAML content in it's window, and is (_typically_) run as a packaged application. > > The lines between what constitutes a "UWP" and a "Win32" application are becoming more and more blurred every day, and the Terminal is a great example of a hybrid application that can utilize both technologies. > > It looks and feels like a UWP app though. Maybe that's the problem. It is the direction Windows is moving in, so its not like it looks like UWP, but Windows is moving towards that UI everywhere.

claunia commented

@ghost commented on GitHub (May 14, 2020):

It is the direction Windows is moving in, so its not like it looks like UWP, but Windows is moving towards that UI everywhere.

Well, I can't really do anything about that other than to give feedback as I am doing, and avoiding Windows updates and eventually moving out of the Windows platform.

@ghost commented on GitHub (May 14, 2020): > It is the direction Windows is moving in, so its not like it looks like UWP, but Windows is moving towards that UI everywhere. Well, I can't really do anything about that other than to **give feedback** as I am doing, and avoiding Windows updates and eventually moving out of the Windows platform.

claunia commented

@AnuthaDev commented on GitHub (May 14, 2020):

I mean, that's a possibility

So you're telling me there's a chance 🤣😅

I hope winUI 3.0 alleviates this situation.

@AnuthaDev commented on GitHub (May 14, 2020): > I mean, that's a _possibility_ So you're telling me there's a _chance_ 🤣😅 I hope winUI 3.0 alleviates this situation.

claunia commented

@DHowett-MSFT commented on GitHub (May 14, 2020):

@AnuthaDev it’s nowhere near ready for primetime use (by developers who we can’t go bother when stuff goes wrong), but this repository does produce a WPF control that’s really just a standard Win32 HWND with the terminal surface on it. It’s pretty much the DirectWrite renderer wired up to a surface.

Our long term plan sees us producing composable controls other developers can integrate into their own experiences.

If only we had all the time in the world 😄

@DHowett-MSFT commented on GitHub (May 14, 2020): @AnuthaDev it’s nowhere near ready for primetime use (by developers who we can’t go bother when stuff goes wrong), but this repository does produce a WPF control that’s really just a standard Win32 HWND with the terminal surface on it. It’s pretty much the DirectWrite renderer wired up to a surface. Our long term plan sees us producing composable controls other developers can integrate into their own experiences. If only we had all the time in the world :smile:

claunia commented

@AnuthaDev commented on GitHub (May 14, 2020):

If only we had all the time in the world 😄

@DHowett-MSFT Okay, serious question. Suppose somebody else does the entire work, what would your preference be XAML or win32 HWNDS (Provided that win32 significantly reduces memory consumpition and startup time)?

@AnuthaDev commented on GitHub (May 14, 2020): > If only we had all the time in the world :smile: @DHowett-MSFT Okay, serious question. Suppose somebody else does the entire work, what would your preference be XAML or win32 HWNDS (Provided that win32 significantly reduces memory consumpition and startup time)?

claunia commented

@mdtauk commented on GitHub (May 14, 2020):

WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen)

@mdtauk commented on GitHub (May 14, 2020): WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen)

claunia commented

@oising commented on GitHub (May 14, 2020):

Well, I can't really do anything about that other than to give feedback as I am doing, and avoiding Windows updates and eventually moving out of the Windows platform.

@phgmacedo Why would you avoid future Windows updates? WinUI 3.0 brings many benefits, and as a dev, you're never going to be forced to update WinUI either. Opting out of Windows updates seems to be counter-productive in general - or are you just making an orthogonal, abstruse gesture about your displeasure? It may be more effective to visit the new WinUI 3.0 site and assuage your worries.

@oising commented on GitHub (May 14, 2020): > Well, I can't really do anything about that other than to **give feedback** as I am doing, and avoiding Windows updates and eventually moving out of the Windows platform. @phgmacedo Why would you avoid future Windows updates? WinUI 3.0 brings many benefits, and as a dev, you're never going to be forced to update WinUI either. Opting out of Windows updates seems to be counter-productive in general - or are you just making an orthogonal, abstruse gesture about your displeasure? It may be more effective to visit the new [WinUI 3.0](https://microsoft.github.io/microsoft-ui-xaml) site and assuage your worries.

claunia commented

@AnuthaDev commented on GitHub (May 14, 2020):

WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen)

Ah, there's a difference between HWNDs and HWND. in XAML there is only parent HWND window, while in classic win32 every control has a HWND

@AnuthaDev commented on GitHub (May 14, 2020): > WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen) Ah, there's a difference between HWNDs and HWND. in XAML there is only parent HWND window, while in classic win32 every control has a HWND

claunia commented

@mdtauk commented on GitHub (May 14, 2020):

WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen)

Ah, there's a difference between HWNDs and HWND. in XAML there is only parent HWND window, while in classic win32 every control has a HWND

Yea, that is a very classic windows concept. Every control is also a Window.

@oising I think he is maybe expressing a preference for the Win32 visual look, compared to the Windows 10/WinUI look. Could be the density of controls, or just an old school familiarity with WinForms / WPF.

@mdtauk commented on GitHub (May 14, 2020): > > WinUI Desktop will use HWNDs for it's window implementation, but will use XAML UI (which uses DirectX to render to the screen) > > Ah, there's a difference between HWNDs and HWND. in XAML there is only parent HWND window, while in classic win32 every control has a HWND Yea, that is a very classic windows concept. Every control is also a Window. @oising I think he is maybe expressing a preference for the Win32 visual look, compared to the Windows 10/WinUI look. Could be the density of controls, or just an old school familiarity with WinForms / WPF.

claunia commented

@DHowett-MSFT commented on GitHub (May 14, 2020):

density

So, WinUI 2 started to offer a "Compact" sizing dictionary that changes control sizes to more closely match classic Win32. That might be worth investigating.

@DHowett-MSFT commented on GitHub (May 14, 2020): > density So, WinUI 2 started to offer a ["Compact" sizing dictionary](https://docs.microsoft.com/en-us/windows/uwp/design/style/spacing) that changes control sizes to more closely match classic Win32. That might be worth investigating.

claunia commented

@DHowett-MSFT commented on GitHub (May 14, 2020):

After testing: on account of we don't have too much UI right now it doesn't really help us.

@DHowett-MSFT commented on GitHub (May 14, 2020): After testing: on account of we don't have too much UI right now it doesn't really help us.

claunia commented

@mdtauk commented on GitHub (May 14, 2020):

Density keeps to the 32px min height for touch controls like buttons and text boxes I believe. The flyouts from the Add Tab button could be affected, but until WinUI 3, flyouts are not affected by setting a compact density.

@mdtauk commented on GitHub (May 14, 2020): Density keeps to the 32px min height for touch controls like buttons and text boxes I believe. The flyouts from the Add Tab button could be affected, but until WinUI 3, flyouts are not affected by setting a compact density.

claunia commented

@DHowett-MSFT commented on GitHub (May 15, 2020):

Now, I'm going to mark and minimize all the complaining about our choice in UI framework as off-topic and turn this into the issue for "make sure terminal launches fast". Kay? Kay.

@DHowett-MSFT commented on GitHub (May 15, 2020): Now, I'm going to mark and minimize all the complaining about our choice in UI framework as off-topic and turn this into the issue for "make sure terminal launches fast". Kay? Kay.

claunia commented

@vannomad commented on GitHub (Jul 7, 2021):

Would running WT in tray be an option? It would not necessarily improve "startup" but it would make it unnoticeable. Would also fix quake mode not running unless there's a WT window open.

@vannomad commented on GitHub (Jul 7, 2021): Would running WT in tray be an option? It would not necessarily improve "startup" but it would make it unnoticeable. Would also fix quake mode not running unless there's a WT window open.

claunia commented

@zadjii-msft commented on GitHub (Jul 7, 2021):

Sure, that's more of a request we're working on over in #9996.

@zadjii-msft commented on GitHub (Jul 7, 2021): Sure, that's more of a request we're working on over in #9996.

claunia commented

@rushfan000 commented on GitHub (Jul 8, 2021):

@vannomad It's well known that windows terminal is extremely slow.

I've been using wezterm for a while. It does not mantain a tray icon, and it is lightning fast, starts up instantly! And even then people complain that wezterm is slow
It most definitely is not slow compared to windows terminal.

@rushfan000 commented on GitHub (Jul 8, 2021): @vannomad It's well known that windows terminal is extremely slow. I've been using [wezterm](https://github.com/wez/wezterm) for a while. It does not mantain a tray icon, and it is lightning fast, starts up instantly! [And even then people complain that wezterm is slow](https://github.com/wez/wezterm/issues/334) It most definitely is not slow compared to windows terminal.

claunia commented

@ssylvan commented on GitHub (Jul 9, 2021):

One thing I didn't see mentioned: Terminal currently starts up slow enough that if you hit enter and start typing, you will not only lose key-presses, you will lose focus, meaning that terminal will never get any input until you click the window.

I.e. you type terminal in the start menu, hit enter, then type "dir" or whatever, that first 'd' will happen long before terminal is actually active, so it gives focus to something else. Where does that keypress go? The "next" window? I'm not sure! Wherever it goes, it activates that window, which then prevents Terminal from getting focus once it gets around to actually launching. And at that point, Terminal will just be an inactive window that doesn't get any input until you take some manual action to give it focus.

So, at a bare minimum: Terminal needs to start up and immediately take focus, then buffer all the input keys so they can be fed to the command line. This needs to happen fast enough that I don't lose focus.

That's the bare minimum, but really in 2021 you shouldn't be able to say "one Mississippi" before a simple app like Terminal is not only launched and activated, but fully initialized. That's an eternity. Really, terminal should be up and running and fully initialized before the key-up event on the enter key that launched it. I realize this is a hard problem because it's very likely the problem is in the UWP/XAML stack. Indeed, calculator suffers from the exact same problem these days, where the new version of the app loses input because it is just sooooo slow to launch. So I get that this may not be something you can entirely fix on your own, but you can add a requirement to the XAML folks to improve their startup performance (as well as do whatever you can do on your own side to mitigate the problem).

Re: the suggestion above about removing XAML, I don't think it's as crazy as it may seem. Indeed, I would argue that taking a XAML dependency in Terminal (and Calculator) before verifying that its performance was acceptable was a mistake. Backing out of that mistake until XAML achieves acceptable performance for core apps like Terminal and Calculator is not at all unreasonable IMO. It really doesn't seem like you actually need XAML for the core window/terminal area at all (maybe keep it for settings and initialize it asynchronously?). It's obviously preferable if XAML can be improved, but if it doesn't improve, the priority should be to meet your users' needs (even if that means not using some newfangled UI frameworks that aren't yet up to par).

@ssylvan commented on GitHub (Jul 9, 2021): One thing I didn't see mentioned: Terminal currently starts up slow enough that if you hit enter and start typing, you will not only lose key-presses, you will _lose focus_, meaning that terminal will never get any input until you click the window. I.e. you type terminal in the start menu, hit enter, then type "dir" or whatever, that first 'd' will happen long before terminal is actually active, so it gives focus to something else. Where does that keypress go? The "next" window? I'm not sure! Wherever it goes, it activates _that_ window, which then prevents Terminal from getting focus once it gets around to actually launching. And at that point, Terminal will just be an inactive window that doesn't get any input until you take some manual action to give it focus. So, at a bare minimum: Terminal needs to start up and _immediately_ take focus, then buffer all the input keys so they can be fed to the command line. This needs to happen fast enough that I don't lose focus. That's the bare minimum, but really in 2021 you shouldn't be able to say "one Mississippi" before a simple app like Terminal is not only launched and activated, but fully initialized. That's an eternity. Really, terminal should be up and running and fully initialized before the key-up event on the enter key that launched it. I realize this is a hard problem because it's very likely the problem is in the UWP/XAML stack. Indeed, calculator suffers from the exact same problem these days, where the new version of the app loses input because it is just sooooo slow to launch. So I get that this may not be something you can entirely fix on your own, but you _can_ add a requirement to the XAML folks to improve their startup performance (as well as do whatever you can do on your own side to mitigate the problem). Re: the suggestion above about removing XAML, I don't think it's as crazy as it may seem. Indeed, I would argue that taking a XAML dependency in Terminal (and Calculator) before verifying that its performance was acceptable was a mistake. Backing out of that mistake until XAML achieves acceptable performance for core apps like Terminal and Calculator is not at all unreasonable IMO. It really doesn't seem like you actually need XAML for the core window/terminal area at all (maybe keep it for settings and initialize it asynchronously?). It's obviously preferable if XAML can be improved, but if it doesn't improve, the priority should be to meet your users' needs (even if that means not using some newfangled UI frameworks that aren't yet up to par).

claunia commented

@DHowett commented on GitHub (Jul 9, 2021):

One thing I didn't see mentioned: Terminal currently starts up slow enough that if you hit enter and start typing, you will not only lose key-presses, you will lose focus, meaning that terminal will never get any input until you click the window.

Yeah, I'm none-too-pleased about that. We're booking launch time perf into 1.11 thanks to this and other discussions (and regressions :|)

@DHowett commented on GitHub (Jul 9, 2021): > One thing I didn't see mentioned: Terminal currently starts up slow enough that if you hit enter and start typing, you will not only lose key-presses, you will lose focus, meaning that terminal will never get any input until you click the window. Yeah, I'm none-too-pleased about that. We're booking launch time perf into 1.11 thanks to this and other discussions (and regressions :|)

claunia commented

@ssylvan commented on GitHub (Jul 9, 2021):

Just did a quick trace with some selected events:

So while XAML is indeed taking up a fair mount of time, it doesn't seem like it's responsible for most of it. For example, do we really need to wait until >1s in before we launch the processes for conhost and cmd.exe? Or could we launch them right away (in parallel with all the other processes that launch, and in parallel with XAML initialization)? And why is this ScriptedSandbox64 launched so late compared to the rest of the processes (no idea what that is).

Note that nothing really happens until 240ms in, so I guess that's the sort of "floor" of how long windows takes to launch anything (and maybe launching via VS is an issue here too).

Looking at the UI thread:

Again we see a big gap before anything happens at all on the UI thread, but then there's another big gap in the center before we reach the steady state rendering at the end. That middle gap seems to be mostly about the setup that happens in the render thread initialization (part of this is a slow initial render I think?):

Perhaps the render thread could be initialized at the very beginning of the process launch rather than waiting for XAML (and conhost/cmd.exe etc.) to finish first? So that it's (hopefully) ready to go by the time it's needed? Seems like it currently needs the swapchain to initialize, so I'd recommend trying to refactor that so you can get most things initialized (esp. DirectX, DirectWrite,
etc.), and then resize at the end and wire it up to XAML.

@ssylvan commented on GitHub (Jul 9, 2021): Just did a quick trace with some selected events: ![image](https://user-images.githubusercontent.com/1365415/125130183-6ef22f00-e0b5-11eb-92ac-f1e8a6b94b4e.png) So while XAML is indeed taking up a fair mount of time, it doesn't seem like it's responsible for most of it. For example, do we really need to wait until >1s in before we launch the processes for conhost and cmd.exe? Or could we launch them right away (in parallel with all the other processes that launch, and in parallel with XAML initialization)? And why is this ScriptedSandbox64 launched so late compared to the rest of the processes (no idea what that is). Note that nothing really happens until 240ms in, so I guess that's the sort of "floor" of how long windows takes to launch anything (and maybe launching via VS is an issue here too). Looking at the UI thread: ![image](https://user-images.githubusercontent.com/1365415/125130454-dd36f180-e0b5-11eb-99b5-68b1ed850a16.png) Again we see a big gap before anything happens at all on the UI thread, but then there's another big gap in the center before we reach the steady state rendering at the end. That middle gap seems to be mostly about the setup that happens in the render thread initialization (part of this is a slow initial render I think?): ![image](https://user-images.githubusercontent.com/1365415/125130629-2ab35e80-e0b6-11eb-82e0-655f8f88c3ba.png) Perhaps the render thread could be initialized at the very beginning of the process launch rather than waiting for XAML (and conhost/cmd.exe etc.) to finish first? So that it's (hopefully) ready to go by the time it's needed? Seems like it currently needs the swapchain to initialize, so I'd recommend trying to refactor that so you can get most things initialized (esp. DirectX, DirectWrite, etc.), and then resize at the end and wire it up to XAML.

claunia commented

@vadimkantorov commented on GitHub (May 31, 2022):

One of my takeaways from https://github.com/microsoft/terminal/issues/6409 / https://github.com/microsoft/microsoft-ui-xaml/issues/2648 was that XAML stack also loads a lot of useless libraries (even including Maps control) and probably this requires at least some useless accesses to hard disk

@vadimkantorov commented on GitHub (May 31, 2022): One of my takeaways from https://github.com/microsoft/terminal/issues/6409 / https://github.com/microsoft/microsoft-ui-xaml/issues/2648 was that XAML stack also loads a lot of useless libraries (even including Maps control) and probably this requires at least some useless accesses to hard disk

claunia commented

@bozhodimitrov commented on GitHub (Jul 26, 2022):

I just want to add feedback for this particular issue:

Currently, the Windows Terminal (1.14.1962.0) cold startup with the default profile of CMD takes at least 3-4 seconds on a new powerful machine: i9-12900K @ 5GHz with plenty of 32GB RAM and NVMe PCIe Gen4 disk ...
Idk what is going on but I tried to eliminate every possible setting to reduce the startup cost, but it's still very noticable for me.
- I tried fresh reinstall of the app, purging the settings folder, installing from the Store/winget/etc... nothing helps.
- Using the Process Explorer from the SysInternals tools, I can see that WT initialization takes significant time, after which, cmd/powershell is started instantly.

Is that the case for anyone else or it's just me?

@bozhodimitrov commented on GitHub (Jul 26, 2022): I just want to add feedback for this particular issue: - Currently, the Windows Terminal (1.14.1962.0) cold startup with the default profile of CMD takes at least 3-4 seconds on a new powerful machine: i9-12900K @ 5GHz with plenty of 32GB RAM and NVMe PCIe Gen4 disk ... - Idk what is going on but I tried to eliminate every possible setting to reduce the startup cost, but it's still very noticable for me. - I tried fresh reinstall of the app, purging the settings folder, installing from the Store/winget/etc... nothing helps. - Using the Process Explorer from the SysInternals tools, I can see that WT initialization takes significant time, after which, cmd/powershell is started instantly. Is that the case for anyone else or it's just me?

claunia commented

2026-01-31 01:22:01 +00:00

@zadjii-msft commented on GitHub (Jul 26, 2022):

Idk what is going on

Ultimately, that's what's important- knowing what is going on here. Measurements of how long it takes on various CPUs isn't helpful. Actual traces of the startup, which can identify the bits of startup that are taking the longest, that's what's actually important to this thread. I've got some traces higher up that we're starting with. We'll start there, unless someone can narrow down some part of XAML init that's more costly that we can trim out.

@zadjii-msft commented on GitHub (Jul 26, 2022): > Idk what is going on Ultimately, that's what's important- knowing _what is going on here_. Measurements of how long it takes on various CPUs isn't helpful. Actual traces of the startup, which can identify the bits of startup that are taking the longest, that's what's actually important to this thread. I've got some traces higher up that we're starting with. We'll start there, unless someone can narrow down some part of XAML init that's more costly that we can trim out.

claunia commented

@bozhodimitrov commented on GitHub (Jul 26, 2022):

I assume that there is something related to Xaml, because while searching on google/github/reddit for this issue, I saw this strange behavior happening at the start bar for several seconds, before the proper WT icon and title gets in place:

Versus

So I assume that it might be related. But sadly Idk how to debug further. I will try to search for additional instructions on how to run a debug build of Windows Terminal or running some kind of profiling.

Btw, I removed the Azure profile, since I don't need it for now, I have only the default CMD and PowerShell profiles. I even added the -noLogo argument for PowerShell in order to avoid the greeting news message that PowerShell provides by default.

PS: I assume that most users use the suspended version of Windows Terminal, which is always running/sleeping in the background and this is why most of them don't notice the cold startup time.

@bozhodimitrov commented on GitHub (Jul 26, 2022): I assume that there is something related to Xaml, because while searching on google/github/reddit for this issue, I saw this strange behavior happening at the start bar for several seconds, before the proper WT icon and title gets in place: ![image](https://user-images.githubusercontent.com/1278836/181060743-2c0ecda4-52c5-4b0c-bac0-25c2f3294f71.png) Versus ![image](https://user-images.githubusercontent.com/1278836/181062043-826372ec-63d5-4349-8dd4-3dcf3927e41d.png) So I assume that it might be related. But sadly Idk how to debug further. I will try to search for additional instructions on how to run a debug build of Windows Terminal or running some kind of profiling. Btw, I removed the Azure profile, since I don't need it for now, I have only the default CMD and PowerShell profiles. I even added the `-noLogo` argument for PowerShell in order to avoid the greeting news message that PowerShell provides by default. PS: I assume that most users use the suspended version of Windows Terminal, which is always running/sleeping in the background and this is why most of them don't notice the cold startup time.

claunia commented

2026-01-31 01:22:01 +00:00

@lhecker commented on GitHub (Aug 5, 2022):

It's probably a good idea to save this here just in case we need it later...
(WPR trace of starting 10 instances of Windows Terminal Preview 1.16.2142.0.)

Edit: The JumpList and cross process COM parts have now been fixed in #13692, which is part of version 1.16.

@lhecker commented on GitHub (Aug 5, 2022): It's probably a good idea to save this here just in case we need it later... (WPR trace of starting 10 instances of Windows Terminal Preview 1.16.2142.0.) ![image](https://user-images.githubusercontent.com/2256941/182979871-1072219b-b6ca-42fe-b298-52f1e4c94426.png) Edit: The `JumpList` and cross process COM parts have now been fixed in #13692, which is part of version 1.16.

claunia commented

@oising commented on GitHub (Aug 5, 2022):

I vote to have jumplist generation opt-in via settings. Seems like a quick win. Who uses jumplists with terminals that much? Is there telemetry on this?

@oising commented on GitHub (Aug 5, 2022): I vote to have jumplist generation opt-in via settings. Seems like a quick win. Who uses jumplists with terminals that much? Is there telemetry on this?

claunia commented

@zadjii-msft commented on GitHub (Aug 5, 2022):

jumplist generation opt-in via settings

Yea I'm not gonna do that. #576 was one of the biggest feature requests. Definitely not gonna disable that by default. A more sensible fix might be to wait until after TerminalPage::_CompleteInitialization to kick off the first UpdateJumplist. I know we're requesting it on a background thread, but I guess presumably, that just creates a thread that could ask for time slices before we've got the window on the screen.

Another optimization we discussed at least on Teams - stashing the initial size in state.json somewhere. Any time we hot-reload the settings, kick a BG thread to evaluate how big the window should be for the initialRows/Cols and the default profile's[1] font settings. On launch, we could avoid the cost of looking up the font to do that math most of the time, just use the dip we already precalculated. That would cause the initial size to be wrong in the case that someone edited the settings.json with the Terminal closed, sure. But that seems like it'd save startup cost most of the time, so it'd be a viable optimization

[1]: heck typing this up, I had better ideas. We could cache each profile's startup size, sure. OR we could just encode into json the DIP for various fontFace/size pairs. Like, { "Cascadia Code": {"12": "8,13"}, ...}. And then regardless of the profile launched, look up the DIP from that precalculated cache. That would only be wrong if the font itself changed, and the cache would only miss again, when the settings are changed w/o the Terminal open.

@zadjii-msft commented on GitHub (Aug 5, 2022): > jumplist generation opt-in via settings Yea I'm not gonna do that. #576 was one of the biggest feature requests. Definitely not gonna disable that by default. A more sensible fix might be to wait until after `TerminalPage::_CompleteInitialization` to kick off the first `UpdateJumplist`. I know we're requesting it on a background thread, but I guess presumably, that just creates a thread that could ask for time slices before we've got the window on the screen. <hr> Another optimization we discussed at least on Teams - stashing the initial size in `state.json` somewhere. Any time we hot-reload the settings, kick a BG thread to evaluate how big the window should be for the initialRows/Cols and the default profile's[1] font settings. On launch, we could avoid the cost of looking up the font to do that math most of the time, just use the dip we already precalculated. That would cause the initial size to be wrong in the case that someone edited the `settings.json` with the Terminal closed, sure. But that seems like it'd save startup cost _most of the time_, so it'd be a viable optimization [1]: heck typing this up, I had better ideas. We could cache each profile's startup size, sure. OR we could just encode into json the DIP for various fontFace/size pairs. Like, `{ "Cascadia Code": {"12": "8,13"}, ...}`. And then regardless of the profile launched, look up the DIP from that precalculated cache. That would only be wrong _if the font itself changed_, and the cache would only miss again, when the settings are changed w/o the Terminal open.

claunia commented

@DHowett commented on GitHub (Sep 12, 2022):

Discussion idea:

Font metrics do not change between machines. We can build a compiled-in cache of font cell sizes at different point sizes for the five most popular fonts (Cascadia Code/Mono, Consolas, Lucida Console, Various types of Fira?) and short circuit the calculation. That will stop us from creating a font collection on every startup.

@DHowett commented on GitHub (Sep 12, 2022): Discussion idea: * Font metrics do not change between machines. We can build a _compiled-in_ cache of font cell sizes at different point sizes for the five most popular fonts (Cascadia Code/Mono, Consolas, Lucida Console, Various types of Fira?) and short circuit the calculation. That will stop us from creating a font collection on every startup.

claunia commented