terminal: Report to users publicly results of: Test Terminal in low-memory; slow hard disk conditions, measure/reduce working set, minimize number of used shared libraries; binary size
In top bar we have + and v buttons.
After not using Terminal for some time (the app was opened, but not used, e.g. after recovery from hibernation), sometimes there’re up to 2-3 seconds passing between clicking on v and context menu drop down appearing. Maybe it’s delay for reading “settings.json” or loading memory pages into physical mem and O.S. being slow, but it’d be nice to have some guarantees on this drop down appearing (it’d better say loading if this can take a lot of time).
Same for + button. It takes me up to 5 seconds hanging before the tab appears (I’m not even talking of the title being shown and WSLv1 bash started).
After I’ve used these buttons couple times, they become faster, but still lag noticeably:
+ button maybe takes up to 100-200ms (judging by eye)
v has some 50-100ms delay
I wonder if these can be optimized to appear instantly and then do some loading, then one has a feeling that terminal does not hang and is doing some work.
It’d also be good if new tab instantly prints some temporary title, before the shell loads. Currently it’s empty for up to 1 second (time of hanging + loading the shell inside the tab).
This is on version: 0.11.1333.0
It would also be nice to have these delays printed somewhere in the logs (maybe if some debugging mode is enabled), so we can easily pull them out, understanding that time-to-rendering may be hard to extract from the UI framework. But it’d be good to have for diagnostics, since terminal must be super-fast. E.g. I stopped using calc.exe and Windows Photo Viewer, since they take up to 5-10 seconds to load and render (probably because of using slow UI framework and requiring a lot of libraries loaded from disk), so I want my terminal + python loading fast for calculation needs 😃
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 1
- Comments: 26 (10 by maintainers)
I mean, I’d love to use something more performant and consistent with Windows UI guidelines, if it existed. I’m not sure which of the following would have been a better choice though:
If there are performance problems with using WinUI XAML in the Terminal, I’d much rather use those performance issues to help drive improvements within the framework to benefit all Windows applications.
So far my current/inconclusive summary (discussion continues in that issue) is that WT has a quite large WorkingSet: 65Mb wtih PrivateBytes: 200Mb (one WSLv1 tab open) according to Procexp, and uses a lot of shared libraries and also some fonts. In low memory conditions they only start loading from disk synchronously when a user interacts with the UI.
So one goal could be to have a WT app with a smaller working set and include used memory resources in key metrics
Another could be starting loading shared libraries/unswapping in background once the user focuses the app. An opposite direction could be somehow making sure that no unnecessary / very few libraries are loaded while basic UI interaction.
One way for prevention could be somehow showing a some message UI libraries are loading (but putting the message may itself be tricky if UI libraries are not loaded), but at least Windows has a way to check if memory pages are not in physical memory yet: https://stackoverflow.com/questions/51342150/how-to-determine-if-a-logical-address-is-in-physical-memory, or at least putting some message after they are loaded indicating that WT lacks memory for smooth operation.
Maybe also one way could be asking to never page WT on disk (or have such option). I’m not sure if this is possible. Right now Google Chrome always eats all memory 😃
E.g. WT has Windows.UI.Xaml.Phone.dll, Windows.UI.Xaml.InkControls.dll, Windows.UI.Xaml.Maps.dll in modules list while I use WT on a regular laptop and no intention of using maps 😃
Related tricks about hinting Windows to not swap out or to swap in the process in one go: https://stackoverflow.com/questions/1039017/can-i-tell-windows-not-to-swap-out-a-particular-processes-memory https://superuser.com/questions/600698/is-it-possible-to-hint-windows-to-bring-a-process-completely-out-of-swap
Well, I understood that you don’t have generic UI perf tracing at the moment 😃 It’s quite unfortunate, but I’ll create an issue in XAML. Let’s see what they say.
Me too, it’s just that specific app-context is important. And tracing may require cross-linking with app-specific events. E.g. in the linked calc.exe issue one of linked PR was delaying loading some libraries and reducing working set size. Look at advice an author of a performant XAML app gave there - it’s quite app-specific. If the problem is with too-large working set and loading too many UI libraries at button click, a solution could be preemptive library loading to memory when Terminal gets focus or maybe load some settings from disk preemptively in the background and not on UI thread.
But anyway, I’ll create an issue and discussion can also continue there.
I’ll ask them, sure. Just I have zero context about how Terminal uses XAML framework. Unless they have a ready recipe for instrumenting Terminal, this will likely not go anywhere.
The fact that you do not have done UI perf instrumentation before is troubling, especially given the known problems with XAML perf on not giant machines. Especially for such a core app like Terminal (arguably even more core than calc.exe or Photo Viewer).
It’s Terminal team that made the choice of UI framework, I think it’s expectable for users to report perf problems to Terminal team and at least get help with instrumentation / proper measurement.
If you choose to refer regular terminal users to directly communicate with Microsoft UI Xaml team, that’s like hoping that regular users are all like Bruce Dawson and can independently do a complete investigation and serve as liaison between Terminal and XAML => a lot of burden and very little chance for success. I’m a regular user, not a perf engineer.
There are long-standing similar requests in Windows Calculator: https://github.com/microsoft/calculator/issues/209
I’ll record a gif next time I recover from Hibernate. I understand that it’s probably XAML that’s not fast enough (and . A more satisfactory response would be if Terminal could push the XAML framework team to improve performance or at least do logging/tracing performance in order to have some numbers to record/inverstigate/profile perf as an end-user (including enabling this for an already running app). Maybe terminal could somehow ask Windows to not unload Terminal pages to disk or to not do memory compaction to them.
It’s definitely hardware to blame: I have too many Chrome tabs (with a Great Suspender, but still it eats a lot), only 8Gb and HDD. It’s an old-ish Lenovo L470.
But still, even on little RAM resource (most likely that’s the problem) Terminal would better be fast and use very little resources on its own.
So for the record, those buttons are built statically when the Terminal is first launched or the settings are reloaded. If there’s any delay in them appearing for you, it’s not coming from our code, it’s probably lower down in the XAML stack.
On my machine, that dropdown appears instantly, and tabs appear (reasonably) fast, though the animation for the tab could use some improvements. The tab content certainly appears instantaneously.
What kind of hardware are you working with on your machine?