Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Both WT and Powershell are great, but the startup is a little slow when combined together. And my some thoughts. #17642

Closed
flyingcat opened this issue Aug 1, 2024 · 3 comments
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting

Comments

@flyingcat
Copy link
Contributor

Description of the new feature/enhancement

As the title described. On my computer(AMD Ryzen 3600, even slower on Snapdragon 8cx Gen 3):

→ D:\tmpdir\terminal-1.22.2081.0
> Measure-Command { Start-Process .\WindowsTerminal.exe -PassThru 'pwsh','-c','exit' | Wait-Process } | % TotalMilliseconds
757.2283

I do want to help, but after some digging into the code, it quickly turn out that its complexity is far beyond my level. However I think the ideas maybe somehow helpful for core team, so I just take some time to this.

Proposed technical implementation details (optional)

  1. Start profile's command line as early as possible, ideally right after settings loaded. Then the startup of pwsh.exe will overlap with UI initialization. However I don't know it's valid or not, as I am not familiar with terminal things.
    image

  2. Made subsequent process run faster. Currently it need to load the whole settings to get the value of compatibility.isolatedMode , which in turn cause time-consuming WindowsXamlManager::InitializeForCurrentThread() in App::App(). It should be avoided, or better, avoid loading the whole settings too.

    → D:\tmpdir\terminal-1.22.2081.0
    > .\WindowsTerminal.exe; Start-Sleep 2; Measure-Command { Start-Process .\WindowsTerminal.exe -PassThru | Wait-Process } | % TotalMilliseconds
    175.0779
  3. Create spare window thread on idle time after new window showed. Add an option to allow keep running in background just like Edge and tweak auto launch on boot to adapt it. Now event if the first is hard to implement and pwsh.exe is still slow to start, we at least always get quick UI response.

@flyingcat flyingcat added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Aug 1, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Aug 1, 2024
@lhecker
Copy link
Member

lhecker commented Aug 1, 2024

I like your first 2 suggestions. I did plan to try and make the app launch faster for the next release after this one (i.e. we're currently working on 1.22 which will release in a month, and I'd like to investigate it afterwards in 1.23).

The 3rd point (Edge-style auto-launch on boot) is something I dislike. Instead of not hurting the victim outright (the user), you simply hurt the victim secretly when they don't pay attention, which is IMO morally reprehensible. It doesn't achieve any lasting progress, and in fact it may lower our chances from getting the fundamental issue fixed (which is Edge's and WinUI's continuously worsening performance). (However, I don't mind keeping an instance of WT running after it first launched, which I is something we already support.)

@flyingcat
Copy link
Contributor Author

flyingcat commented Aug 1, 2024

The 3rd point (Edge-style auto-launch on boot) is something I dislike. Instead of not hurting the victim outright (the user), you simply hurt the victim secretly when they don't pay attention, which is IMO morally reprehensible. It doesn't achieve any lasting progress, and in fact it may lower our chances from getting the fundamental issue fixed (which is Edge's and WinUI's continuously worsening performance). (However, I don't mind keeping an instance of WT running after it first launched, which I is something we already support.)

Yes, It's already implemented 👍 https://learn.microsoft.com/en-us/windows/terminal/customize-settings/startup#continue-running-in-the-background-preview

I think you maybe misunderstood me. I don't mean auto launch secretly. I mean combine startOnUserLogin with compatibility.allowHeadless: launch quietly with showing a tray icon, just like a dictionary App or something similar.


Is this on purpose or just a bug, all windows closed.
image

@lhecker
Copy link
Member

lhecker commented Aug 1, 2024

That's a bug for sure. I believe we've already come across this before. We're tracking parts of that issue in #17420 among others.

@microsoft microsoft locked and limited conversation to collaborators Aug 7, 2024
@carlos-zamora carlos-zamora converted this issue into discussion #17683 Aug 7, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting
Projects
None yet
Development

No branches or pull requests

2 participants