Jumplist performance is still too slow - 200-250 ms to display a menu about windows-dev-performance HOT 35 CLOSED

Reopening this issue as the product team are investigating. Will share the result of their findings once they solidify.

from windows-dev-performance.

My experience is that many of the "modern" things introduced in Windows 10 are much slower. To name a few:

• Calculator, compared to the classic pre-UWP calculator (there's also an issue about launch time).
• Photos app, as opposed to the classic "Windows Picture and Fax Viewer". I wait 2-10 seconds for it to just display a picture! One of the first things I do on a fresh system is to set-up the old viewer, but MS started hiding it so it has to be done via registry. Finally I found a third party app which is also maintained.
• The start menu took very long to show up in early Windows 10 versions as opposed to Windows 7. Since it's so essential in Windows, I believe at least this part was optimized with time.
• This very thread - Windows 10 jump lists as opposed to the Windows 7 jump lists.
• Various taskbar flyout items - calendar, volume, network, etc. I believe it had overgone some optimizations as well, in early Windows 10 versions it was just horrible.

Maybe more stuff I can't remember at the moment.
It's sad that performance doesn't directly translate to money so MS doesn't have the incentive to invest in profiling and improve performance. If the QA team (if MS still has one) would try using Windows on a 10 years old computer, and report any basic action that takes more than 0.5 seconds to execute, Windows could be much more pleasant to use.

from windows-dev-performance.

I'm surprised Microsoft reopened this, rather than just saying that it's "out of scope" and telling you to file an issue on the Feedback Hub. I guess they really do give special treatment as you are a pretty important person. Not enough that they'd fix it of course lmfao.

It's even slower when you drag/swipe up on a taskbar icon! It focuses on the first icon first and then opens the jumplist. You're lucky to have a delay of a few hundred milliseconds. People with slower CPUs have it worse, as you mentioned in your post. The Windows 10 20H1 update didn't noticeably reduce the delay for me.

while I'm here, let me mention that task view was ruined in v1803. The touch keyboard was ruined in v1709 but it finally performs kinda normally, three years later (but still dismisses itself when you press a key on your physical keyboard!). Snap with win+left/right is bugged starting with v1903. The Edge tab integration in alt+tab that was introduced in v20H2 is incredibly buggy, proportional to the number of tabs you have, even when turned off!
When Windows Explorer is broken because of Edge, I just try opening the Task View! :P

I did of course file issues for each of the above bugs. I won't be filing any more though. Microsoft has shown that they refuse to listen to its Windows users.

P.S. I really loved your video too. Thank you.

P.P.S Another very slow experience that justanotheranonymoususer didn't mention is the Movies & TV app. I've seen it take forever and often eventually crash on so many systems. Why those people put up with it - I'll never understand. Snip & Sketch and Settings are also slow to open. There aren't that many UWP apps... Only a small part of MS admits that UWP is dead. It's funny how apps like Pictureflect show you what it looks like when a developer not only cares for their app but use it themselves too. It's a UWP app and it's right up there with IrfanView and the like.

from windows-dev-performance.

Could you keep this issue open until we see the improvements in insider builds?

from windows-dev-performance.

Thanks for the detailed feedback!
The focus of the windev repo is on developer tools and scenarios that impact the developer experience. For general OS performance problems, the feedback hub is still your best bet. If you file a feedback hub issue I'd be happy to give folks a heads up about it :)

from windows-dev-performance.

Good news: somebody already filed a feedback request for allowing longer feedback requests - https://aka.ms/AA1vcsz
Bad news: you can't upvote it because your company (mine also) blocks Feedback Hub
Good news: I upvoted it from my personal machine - apparently a personal Windows machine is required now
Bad news: "We looked into this feedback in greater detail, and discovered that on average, the vast majority of people submitting feedback use far fewer than our 1000 character limit, so for now, we've decided to keep the limit to 1,000 characters"

That makes no sense. If most people use less than the limit then increasing the limit would not help or harm or affect most people. But it sure would help me.

Sigh...

from windows-dev-performance.

I also experience this problem.

• Windows 1909 (10.0.18363.1082)
• System animations off
• SSD drive
• 16 GB RAM, i7-3770 3.40 GHz
• Jumplists for programs without jumplist items appear almost instantaneously (eg. spotify)
• Jumplists for programs with 10~ jumplist items appear after about 1 second (eg. explorer, notepad, visual studio)

I remember that this was not the case with Windows 7. Over the years, this problem has significantly reduced the frequency at which I use jumplists (now almost never).

from windows-dev-performance.

Somebody reminded me that one reason I invoke the task-bar menu is so that I can then right-click on the application name to bring up another context menu, and then click on properties.

The second menu is even slower than the jumplist menu, and there is a noticeable delay before the properties window appears. Three clicks, each with noticeable delays - it would be great if the end-to-end latency for this scenario - at least on big-memory machines - could be greatly improved.

When bringing up the first menu one of the first things that happens is that RuntimeBroker.exe does a bunch of loading of data. This by itself takes about 45 ms. But, I need to stop poking at this - without source-code access I am just guessing about what is going on

from windows-dev-performance.

@bitcrazed Yeah, of all the issues in this repo, the single most impactful improvement that Microsoft can make to improve my experience on windows as a developer is to make the UI faster and less laggier (saying that windows ui is slow and laggy today would be a serious contender for understatement of the decade). While the other issues in this repo are, well, nice improvements, as a developer I hit this kind of issue multiple times a day.

from windows-dev-performance.

Is there a feedback hub item for this issue? I can't file one on this computer but it would be good to have one that others can follow along with. I understand closing issues that are out-of-scope for this bug database, but it feels like that action should include a link to a replacement item in the correct bug database, otherwise we have no way to track the ongoing work.

from windows-dev-performance.

Hey all. Hope you don't mind, but I am going to close this issue for now as there's work underway to address much of the feedback discussed above, and tracking feedback for the perf of UI features is (as @Poopooracoocoo kindly points out) best filed via Feedback Hub along with recorded repro steps.

Thanks for taking the time to share your views and observations - they've helped us prioritize some of our future work.

from windows-dev-performance.

I don't know if there's already something filed that others are following, but if you file an issue under "Desktop Environment -> Taskbar", and then paste a link to your feedback item here, others can add their thoughts, repro steps, etc. too.

from windows-dev-performance.

@phgmacedo Appreciate the feedback and sentiment - we're in close alignment here.

However, the best thing you and everyone else in the community can do to help us is to file issues that are as specific as possible, with repro steps that demonstrate the issues you're seeing, so that we measure and trace the issue, work to identify a root cause, and an appropriate fix.

"Windows UI is too slow" is a sentiment we can understand, but can't do much about.

"File explorer takes 90s to delete a folder that contains 3M files" on the other hand, is specific, measurable, reproducible, and something we can work to fix.

So please file detailed, specific, targeted issues, and we'll work with you to diagnose and fix.

from windows-dev-performance.

FIXED – WINDOWS 10 JUMPLIST DELAY OPENING JUMPLIST FOLDERS FROM WINDOWS EXPLORER TASKBAR ICON

Hey Gang. I’ve been running Windows 10 Pro x64, and have been experiencing Jumplist delay of about 1-2 sec when trying to open jumplist folders from Windows Explorer Taskbar Icon. After hours of researching and testing, I discovered that my issue was caused by two Explorer Context Menu Items (GDContextMenu64.dll) added by Google’s Backup and Sync app.

I used CCleaner (Free) to disable these two context menu items:

*Directory GDContextMenu
*Drive GDContextMenu64

Then I relaunched explorer.exe, and NO MORE JUMPLIST DELAY!!! 

See image below. In CCleaner, you can navigate to TOOLS, and select the CONTEXT MENU tab to access and enable/disable the Explorer context menu items.

https://imgur.com/gallery/ZYbR2eC

from windows-dev-performance.

I filed a feedback hub issue. I started by pasting in my detailed initial report from here but that exceeded the Feedback hub limits (really?) so I had to trim it and then link to here.

The character-count limits of Feedback hub are yet another reason that it is a frustrating way to give detailed bug reports, FWIW.

The feedback link is at https://aka.ms/AAc1tlz

from windows-dev-performance.

Hey @Fasteroid. Appreciate that you'd like this kept open, but shell UX issues like this are better handled by reporting via Feedback Hub along with a repro recording. I recommend adding to Bruce's FeedbackHub link, above. This way your report, and recorded traces etc. get sent directly to the team who owns the feature and is best positioned to be able to address the issue.

from windows-dev-performance.

from windows-dev-performance.

The initial issue was "reported" here:

https://twitter.com/BruceDawson0xB/status/1170952343212322816

More details were included here:

https://randomascii.wordpress.com/2019/09/08/taskbar-latency-and-kernel-calls/

However that is mostly just for historical reference as that issue has been fixed, thereby exposing the remaining slowdowns.

from windows-dev-performance.

I assume that there is an ETW event that fires when the context menu finishes rendering. If so then it would be nice to know what that event is so that I can record it instead of relying on heuristics to estimate the menu latency.

Also, I assume that this ETW event is tied in to Microsoft's Perftrack system so that latency data from the field is available. If not then that should be fixed. Perftrack is wonderful and should have caught both this slowdown and the previous issue.

from windows-dev-performance.

Note that left-clicking on the clock/date icon has similar delays. The exact same analysis (from mouse-up to window focus to rendering) applies and the total time is ~220-290 ms on my high-powered laptop. The vast majority of the CPU time seems to be in XAML.

Note that I had "Show animations in Windows" disabled so I was presumably getting the best-case performance.

from windows-dev-performance.

ETW trace is here:
https://drive.google.com/file/d/1-lRxvwdh-UqU6p09p6qHC2W-OIqonUZK/view?usp=sharing
Twitter discussion is here:
https://twitter.com/BruceDawson0xB/status/1297262921441898496

from windows-dev-performance.

Here's another data point if needed (Surface Book, i7, 970m gpu, high-perf power setting):
https://drive.google.com/file/d/1F-lhH1A8YP9-kiHc5ugBtbO4ql-BxpmO/view?usp=sharing

I didn't include opening the calendar, but I can confirm that it takes 1sec before showing up. Wifi and battery also takes 1 full second to show.

from windows-dev-performance.

The pattern looks different in that trace. I can see the right-mouse clicks on the task bar and then a burst of CPU and GPU activity that lasts about 220 ms. but the window focus changes are totally different - ShellExperienceHost never gets focus. It looks like you're on an insider build and they have changed some things. Since I don't have source-code access and can only guess about what's happening I will leave this for the experts.

It's also possible that you're doing things differently from how I do them. Again, I defer to the experts.

from windows-dev-performance.

The pattern looks different in that trace. I can see the right-mouse clicks on the task bar and then a burst of CPU and GPU activity that lasts about 220 ms. but the window focus changes are totally different - ShellExperienceHost never gets focus. It looks like you're on an insider build and they have changed some things. Since I don't have source-code access and can only guess about what's happening I will leave this for the experts.

It's also possible that you're doing things differently from how I do them. Again, I defer to the experts.

I was indeed running on a preview build. My process was right click, then click on desktop to close the menu. Not sure why it didn't ever get focus.

from windows-dev-performance.

If you are on Windows 10 1909 then you are seeing a particularly egregious issue that was reported last year and was fixed in Windows 10 2004. When you upgrade the latency should drop by about 70%. Details are here:

https://randomascii.wordpress.com/2019/09/08/taskbar-latency-and-kernel-calls/

from windows-dev-performance.

• Jumplists for programs without jumplist items appear almost instantaneously (eg. spotify)
• Jumplists for programs with 10~ jumplist items appear after about 1 second (eg. explorer, notepad, visual studio)

Thanks @antiufo, I now know what a jumplist is. I also notice on my Windows 10 Pro 1909 I have never been distracted by this. If 2004 every installs successfully, I will see if I notice anything.

from windows-dev-performance.

I have Google Backup and Sync installed and I have that DLL and I have not disabled it but I am not seeing 1-2 second delays in the task menu. What version of Windows 10 are you running (winver will tell you).

If you are interested I can investigate why you are seeing such huge slowdowns from Google Backup and Sync. If you reenable those two DLLs you can then use UIforETW to record a trace of bringing up the context menu. The default settings will work pretty well but it would be helpful to check "GPU tracing" and perhaps change from "Circular buffer tracing" to "Tracing to file". You can find instructions on how to get UIforETW here:

https://randomascii.wordpress.com/2015/09/01/xperf-basics-recording-a-trace-the-ultimate-easy-way/

If Google Backup and Sync is really causing such huge delays then I can try to get it fixed.

This is separate from the slowdowns inherent to the OS implementation of the jump lists.

from windows-dev-performance.

from windows-dev-performance.

There's no need for a trace with the suspect DLLs disabled, I don't think. If they are causing that severe a slowdown then they should be showing up clearly in the trace.

The trace files will be on the order of 20-200 MB, so too big to email. Dropbox or google drive works well.

from windows-dev-performance.

Having this problem again as of KB5003637 and KB4023057.

from windows-dev-performance.

@bitcrazed, Is there anywhere we can file a bug report for increasing the character limit of descriptions in Feedback Hub?

from windows-dev-performance.

@bitcrazed, Is there anywhere we can file a bug report for increasing the character limit of descriptions in Feedback Hub?

I would +1 that. Several times I have filed bugs here, been told to move them to Feedback Hub, and have then had to delete two thirds of the detail. It's pretty frustrating to be told to use Feedback Hub and then not be given enough space to describe any complex issues.

Which is to say, file a Feedback Hub issue against Feedback Hub and I will +1 it.

from windows-dev-performance.

@randomascii Haha, yes, actually I was thinking of this because of comments that I'd seen you make 🙂

My company blocks Feedback Hub, so I'm afraid I don't have any way to file feedback through that means.

from windows-dev-performance.

and tracking feedback for the perf of UI features is (as @Poopooracoocoo kindly points out) best filed via Feedback Hub along with recorded repro steps.

excuse me??

i aint buyin that sht. y'all just closing the big issues so y'all don't have to fix them smh.

I was happy to see a response by Microsoft on these kinds of issues and you close it saying it belongs in the void. You completely missed when I said this:

I did of course file issues for each of the above bugs. I won't be filing any more though. Microsoft has shown that they refuse to listen to its Windows users.

Why do you effing think people started making issues in this repo? 🤦🏿‍♂️

good luck with windows 11 😂😂😂

from windows-dev-performance.

@randomascii, I've filed #93 to discuss the issue of Feedback Hub being blocked on machines at larger corporations 🙂

from windows-dev-performance.