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

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.
    • 

and the Terminal needs to stand up a XAML stack

XAML stack means UWP?

[mdtauk]

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

[zadjii-msft]

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.

[AnuthaDev]

@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.

[zadjii-msft]

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

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.

[mdtauk]

@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