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

[ghost]

Steps to reproduce

1. Click to launch Windows Terminal

Expected behavior

Windows Terminal should be ready instantaneously like windows console, or like Sublime Text.
Windows Terminal can't be slower than windows console.

While Windows Terminal is fast compared with other tools like Visual Studio, or iTunes, it is still not fast enough for a Terminal application.

Actual behavior

It takes too long to startup. It is not ready instantaneously. It's not as fast as windows console.

---

maintainer note: hijacking OP for task list:

• Use exactly one ColorPickerFlyout for all tabs, and just redirect it to whatever tab activated it.
• Delayload the ColorPickerFlyout.
• Add a setting to disable ALL fragments / dynamic profiles. The app catalog search is expensive.
  • Maybe we can just skip loading dynamic profiles on initial launch, unless we discover that the defaultProfile is a dynamic one... Nah, cause what about for defterm launches that end up matching a dynamic profile.

[zadjii-msft]

I mean, the Terminal is doing a lot more than the console ever was. I'm not sure there's much more we can do to optimize our UI setup. Conhost was using basically the simplest Win32/GDI interface possible, and the Terminal needs to stand up a XAML stack. Even if we somehow had a server process that already had the settings pre-loaded, we'd still need to stand up the UI stack.

At least the Terminal is faster at processing output than the console ever was, and opening new tabs/panes is certainly faster than opening a new conhost is.

Maybe there's something we can do here to optimize the creation of the XAML stack.

---

7/21/2022 edit: putting this here so it doesn't ping everyone on this thread.

While investigating another issue:

• parsing the json is the green column.
• Looking for fragments is wholly 50% of the settings load cost
• Az cloud Shell is another 20% (Just creating the IAzureConnectionStatics is that expensive? That's crazy. Hard to be sure, I don't have symbols working 😕)
• In this trace:
  • TryLoadSettings is 44/284 for the AppHost ctor
  • ctoring the XAML resources is 62/284 for the AppHost ctor, of the 139 for just instantiating App
  • instantiating the CmdPal looks like another 30/284
  • Outside of the apphost ctor:
    • opening a new tab is like 53 (_CreateNewTabFromPane), creating the color picker flyout is 15 of that.
    • 

[DHowett]

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.

[vadimkantorov]

In #15001 a related usecase: Windows OS running some autoruns do quick cmd.exe some_script.cmd that do not print anything and do not require user input. This spins up many Terminal instances and it's quite slow. The special thing about this usecase is that if the script completes quick, it was worthless of doing full XAML loading and such. So if full rendering can be delayed and then skipped completely because of exit in 500ms, it'd be a big win.

[lhecker]

With the recent barrage of improvements, I've made a new perf trace today. This time using Nvidia Nsight Systems, because it has a neat way to represent delays (zoom in as needed):

Of the remaining ~400ms ~320ms launch cost of Windows Terminal, about 240ms (60% 75%) are due to WinUI and XAML. There are some things we can do about that, but it'll be very difficult, because WinUI isn't exactly easy to manipulate into being lean. For instance, the C++ XAML generator has a bug, where it doesn't emit metadata for system types into our metadata cache. When WinUI then starts, it tries to look up those system types, can't find them and will look around in all registered user providers. This causes Microsoft.Terminal.Settings.Model.dll and everything else to be loaded, which takes ~10% (maybe more). Preventing this isn't easily possible, because creating 2 metadata caches (one for WT and one for the settings model) isn't documented and probably not supported. Most of the time is spent in the layout and rendering code¹ though and that's an area we can't improve upon.

Another 80ms (20%) are caused by our workaround for #11648, a bug which still isn't fixed in Windows unfortunately. I've been thinking about just adding a setting that will load the nearby fonts if the setting is enabled. I don't think caching the font size is a good idea because that would only improve launch time by 10% instead of the expected 20%. It would worsen the user experience for some but improve it for others. This is what I'd like to fix asap. It's the easiest improvement we can make at this point. Fixed.

The remaining 80ms (20%) will be difficult to fix. For instance, HWND creation costs 20ms and we need at least 2 (main thread + 1 for each window). Setting up the Monarch COM server and negotiating that costs another 5-10ms, by nature of COM setup being slow. We allow loading fragments via the app extension catalog, which is an LPC and extremely slow (10ms for returning an empty list). That's almost the entire cost already.

Footnotes

1. FizzBuzzEnterpriseEdition ↩

[vadimkantorov]

As Terminal users, we can upvote certain issues/bugs (that are preventing Terminal from being faster) on XAML github if they have github repo and you link these bugs :) same for any linked Feedback items about general appx slowness which you consider slowing Terminal.

Also, earlier I noted that my Terminal loads a ton of unrelated DLLs, including something related to Maps controls.

[eduarddejong]

If I may add anything functional here. I can imagine that a possible solution would be to differentiate between 2 different ways of starting the Terminal:

1. Opening the application by explicitly clicking it as a user, whether that is via a shortcut or the right click menu in a folder.
2. Automatic launches by several console application executions when being configured as the default terminal in Windows, which would otherwise launch the old conhost.exe console window of windows.

When launching the first way, I love features, and startup time does not matter that much.

When launching the second way, the application should be absolutely blazingly fast by really not loading any more resources than it needs. Because these launches can happen a lot of time after each other. For example when running any kind of automated batch operation.

I don't know if this is possible, but it might be helpful as an idea.

[tadghh]

Removing the Azure profile resolved slow startup times in WT-Preview, before there was a constant 600ms delay spent "loading user and system profiles"

[DHowett]

Removing the Azure profile resolved slow startup times in WT-Preview, before there was a constant 600ms delay spent "loading user and system profiles"

Windows Terminal does not control what happens during "loading user and system profiles" inside powershell. None of Terminal's profiles are used in that process.

The term "profile" is overloaded here; they mean Profile.ps1 (and friends.)

[tadghh]

Removing the Azure profile resolved slow startup times in WT-Preview, before there was a constant 600ms delay spent "loading user and system profiles"

Windows Terminal does not control what happens during "loading user and system profiles" inside powershell. None of Terminal's profiles are used in that process.

The term "profile" is overloaded here; they mean Profile.ps1 (and friends.)

very odd. been having a consistent "startup took ~600ms", removed the other "windows terminal" profiles and it went away. Whos printing the startup delay, its through powershell isnt it?

[DHowett]

Yes, it's PowerShell. The powershell.exe process starts up, loads up the CLR, starts up a PowerShell host engine, starts parsing everything and then prints the message when it's done.

Terminal's job here is to spawn powershell.exe and then read the text it prints.