Investigate launch performance issues

[ssylvan]

Launch the app. It takes about a second to start. This means you almost certainly lose input if you start typing right away (especially if you have a "calculator" button).

Steps To Reproduce

1. Press calculator button on keyboard.
2. Immediately start typing 2+2 on numpad (as an example.. whatever it is you're trying to calculate).
3. A second later calculator launches
4. You will probably have lost at least the first 2, and maybe also the + and second 2, because the app didn't launch fast enough.
5. Result: you have to press the button and consciously wait (feels like an eternity) for the app to start before you can do what you wanted to do.

Expected behavior Calculator should launch fast enough that you can just start typing the thing you're trying to calculate after pressing the calculator button (maybe around 100ms or so).

Device and Application Information (please complete the following information):

• OS Build: 10 0 16299 0
• Architecture: X64
• Application Version: latest master

UPDATE: This issue is now being used to track recommendations, observations, and investigations into how we can improve the actual and/or perceived launch performance of the app. Any actionable ideas that are identified should be broken out into their own issue for tracking purposes.

[ssylvan]

Note that you could maybe start buffering input earlier and the "play it back" once the app is started, but there is of course a general feeling of jankiness/low quality with a slow app, even if you can avoid losing input. So the better fix is to make it faster, IMO.

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

[luntik2012]

it's windows related problem, everything is slow there

[contextfree]

Note that you could maybe start buffering input earlier and the "play it back" once the app is started, but there is of course a general feeling of jankiness/low quality with a slow app, even if you can avoid losing input. So the better fix is to make it faster, IMO.

Another approach could be to load just the result and expression display immediately on startup and then load in the rest of the UI asynchronously. The launch sequence would have to be carefully choreographed (perhaps using placeholders, animations, etc.) to avoid the feeling of jank you mention, but I think it could be done.

I actually think this might be the right solution, and not a hack, because it seems like this scenario (immediate usage and perhaps launch via keyboard) is inherently much more sensitive to launch performance than any other scenario. For anything else, the current ~1000 ms launch time is basically fine. It would be somewhat nicer if it were ~400 ms, say, but that still wouldn't meet the requirements of the quick keyboard usage scenario. But from there, the effort required to further optimize launch time to 100 ms or less would have negligible benefit for general usage, yet be necessary for this scenario.

So it seems the different cases have very different requirements, which suggests a solution that specifically addresses this difference.

[I-Campbell]

I personally use the keystrokes: Win+R c a l c Enter 2 + 2 Enter Refering to the KLM as detailed at the below link, an expert typist should take 120ms from that first enter being pressed to the 2 being pressed, so this should be used as the ideal case for a design constraint. http://www.cs.loyola.edu/~lawrie/CS774/S06/homework/klm.pdf

Response time will vary by hardware, so perhaps the response time should assume: Expert typist: high end desktop: 120ms Average skilled typist: standard business laptop: 200ms Average non secretarial typist: lowest spec windows machines: 280ms

[MarcAnt01]

I think this is due to uwp framework in general, on my old PC with Intel Core Duo and an old HDD (one of the first PCs with Windows Vista, back in the days lmao) I can reproduce, while on my laptop (HP Spectre X360 first generation) (intel Core i5 5200-U and SSD M.2) it's instantaneous.

[DragoCubed]

Would be cool if the splash screen could be replaced by placeholder UI. IIRC iOS does this.

[OvermindDL1]

Why is there a splash screen for a calculator at all, shouldn't it just insta-load the GUI, it's not a complicated heatmap GUI or something. I've lost so much input over time that has caused so many invalid calculations, this is a really bad issue...

EDIT: For note, it is over 1 second to even get to the splash screen (Win10Pro, sometimes up to 2 seconds, and this is very much not a low-end machine), then the splash screen itself takes yet another second to go through, this is pretty crazy when Chrome loads from a fresh reboot in <1second...

[Stanzilla]

That's an issue with all UWP apps and the framework, not really Calculator related, no?

[MarcAnt01]

That's an issue with all UWP apps and the framework, not really Calculator related, no?

Yes, most issues here are, just wondering why collaborators and members of organization don't close them

[HowardWolosky]

Yes, most issues here are, just wondering why collaborators and members of organization don't close them

@MarcAnt01 - I'm curious which other issues you are referring to. I agree that Issues which are generically against the platform/framework shouldn't remain open in this repo. We kept this Issue open since there has been discussion on things we might be able to do (within the scope of our app) to improve its launch experience.

[ssylvan]

I'm not sure I agree that issues should be closed just because it has a (partial) dependency on another team.

"Calculator is too slow" is an issue with calculator. Yes, it may be that to fix it fully someone has to raise the issue with the UWP page and link this one too it. But just because it's partially someone else's problem doesn't mean it's not also Calculator's problem and should be tracked here.

At the extreme, Calculator could choose to move away from the UWP framework to eliminate the issue (or more realistically, try to e.g. reduce the complexity of the XAML/layout graph to mitigate the slowness of UWP by just asking it do less, or any number of other mitigations). Either way, ignoring the issue from the Calculator side doesn't seem like the right choice.

[I-Campbell]

Microsoft have released a handy guide to improve uwp startup performance [1]. I am sure it is at least feasible to capture the keystrokes 120-280ms after the program is called using this guide, with the secondary goal of making the calculator interface viewable/clickable faster than it is now. [1] https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/best-practices-for-your-app-s-startup-performance

[HowardWolosky]

Either way, ignoring the issue from the Calculator side doesn't seem like the right choice.

@ssylvan - We're not ignoring the problem. That's why this issue remains open.

For Issues that we are made aware of which are due to problems outside the scope of our team (like #274), we turn around and open a tracking issue for the appropriate team in their Issue tracking database. This repository is specifically for Calculator, and we're only going to keep Issues open which are actionable within the scope of this project.

[ssylvan]

@HowardWolosky Sorry I was responding to the suggestion that you would close it, not to you! :)

[Geveffe]

This issue is now being used to track recommendations, observations, and investigations into how we can improve the actual and/or perceived launch performance of the app. Any actionable ideas that are identified should be broken out into their own issue for tracking purposes.

[levicki]

@Geveffe That's easy, just use the normal Win32 code and admit that UWP and modern UI is slow junk which nobody wants to use, and nobody asked for.

[ssylvan]

I looked at a trace for this a while back, and it seems like an awful lot of time is spent building data that is known at compile time. Is it possible to parse xaml and produce the initial layout tree at build time (and cache layout between runs after that)? That way the app can just memory map a file and start executing rather than spend half a second parsing text and building a tree in memory.

Perhaps this is limitation with Xaml/UWP right now, but having worked on some performance sensitive apps, this kind of stuff sticks out like a sore thumb. Parsing text and building data structures from on-disk resources should happen at build time, not run time (or at the very least cache it between runs so that only the first run is slow).

[Poopooracoocoo]

I wonder what Pictureflect Photo Viewer does. That's the fastest UWP app I have ever used.

[benstevens48]

Hi, I'm the author of Pictureflect Photo Viewer. I'm not an expert, and on my PC the Calculator app already seems to load quite fast, but I do have some general advice/suggestions.

The most obvious one, which I can see you've already done, is to ensure the splash screen optional attribute is set in the app manifest. The next biggest performance improvement is to ensure that you only add the bare minimum of controls to the visual tree that you need to display the initial UI. Any flyouts, expandable panels etc can be added on demand when the user clicks the relevant button. I think that the Calculator app already does this, except in the case of the left-hand navigation menu, whose contents could be populated only after the user opens the menu rather than on initial load (although I have not used this particular control myself). You can also improve perceived startup performance by delay-loading some parts of the visual tree that are needed in the initial UI. For example, I do this with the welcome screen, else the startup is slightly too long and the splash-screen requirement kicks in. However, note that you need to wait until the window Activated event in order to do the delayed loading. I'm not sure if this is guaranteed to come after the page Loaded event, so I would recommend waiting until both of those have fired.

Another thing to consider is to try to reduce the number of files loaded on startup as far as possible. Also, accessing ApplicationData.LocalSettings could be slow - in my app I store all the settings as a JSON string in one LocalSettings entry - you could investigate to see if this saves any time.

Finally, you can try to reduce the number of DLLs loaded on startup. My knowledge in this area is pretty hazy and I'm not sure what optimizations the system does, but I think that loading DLLs can cost a few milliseconds each. The system ones are not so important as they are likely to already be in memory. However, third party ones will probably have to be loaded - so you can consider the tradeoff between startup performance and the convenience of using third-party libraries at startup. In an app written in C# (not sure if C++ is the same), a DLL will be loaded the first time a method which contains code that uses that DLL is called. This happens even if the code is in a conditional block which is not run. If you have methods like this where the condition is frequently false, then you can improve performance by factoring out the code that needs the DLL into a separate function.

I think the article in the documentation that has been mentioned before covers most of this quite well - https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/best-practices-for-your-app-s-startup-performance.

If you have further questions, I'm happy to advise.

[rudyhuyn]

Thanks @benstevens48 for your input and this very detailed explanation of how a UWP developer can improve the performance of an app (that all UWP developers should follow!), great job!

Performance at launch and during execution is really important to me and I agree with all the tips you have shared. As you noticed, many of these tips are already being used by the Calculator. In addition to these, many internal and community efforts have been made in recent months to further improve start-up performance:

• A totally new numeric pad control
• Optimization of CalculationResult control
• Optimization of OverflowTextBlock
• Optimization of SupplementaryResults
• New TitleBar
• Refactoring of CalculatorProgrammerBitFlipPanel
• Remove serialization/deserialization not used by the application (#370)
• ...

And, even more is coming. Some examples: #379, #648, #60

Regarding the NavigationView, we plan to merge all unit converters, which will remove 11 menu entries and improve launch performance. See #594 for more information.

If you identify an optimization in the application that we should work on, please feel free to create an Issue and if you want, create a Pull Request so the team can review your proposal!

[ghost]

@rudyhuyn I think we should work on gradually porting our C++/CX code to C++/WinRT. This can make drastic improvements in the performance of the application. Refer this article to see a detailed comparison between the performance of apps coded in C++/CX and C++/WinRT.

C++/WinRT is directly based on the C++17 standard which is the reason behind the fact that apps coded in it outperform all others. This also makes the code more portable.

This is highly recommended by Microsoft and I believe that it can be a solution to all the performance related issues that we face.

I am well aware that this is NOT an easy task. But we can ensure that all the new code that comes into this repository follows the C++/WinRT standards, while we can gradually port our older code part by part.

[ghost]

Migrating codebase to C# (#893) would further degrade this app's performance.

[petersenna]

My keyboard has a calculator button, and the slow load time and occasional splash screen are annoying. The startup performance and the blocking splash screen makes the calculator unusable for my use case.