Jumplist performance is still too slow - 200-250 ms to display a menu

[randomascii]

Item	Value
OS, Version / Build	10.0.19041.0 Microsoft Windows NT 10.0.19041.0
Processor Architecture	AMD64
Processor Type & Model	Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz, 3192 Mhz, 4 Core(s), 8 Logical Processor(s)
Memory	32GB
Storage Type, free / capacity (e.g. C: SSD 128GB / 512GB)	SSD 2TB
Relevant apps installed	Windows Performance Toolkit

Description

I frequently right-click on items in the task bar in order to view their properties or close them. Last year I reported a ~500 ms delay due to massively redundant ReadFile calls. This was fixed. However, closer analysis shows that there still remains a 200-250 ms delay from the moment that the mouse button is released until the menu appears. This is well beyond the ideal human interaction times and is a constant frustration. I don't want to wait for my computer, especially when doing simple and repetitive actions that I know it should be able to do roughly ten times faster. Closing multiple programs in this way becomes frustrating, even after the ReadFile fixes.

Steps to reproduce

Right click on a running program on the task bar. Notepad works.

Expected behavior

I expect the menu to appear visually instantaneously. Ideally in less than 50 ms. Certainly in less than 100 ms.

Actual behavior

Note the delay before the jumplist appears. The delay happens with all programs - even Notepad.

I analyzed the delay scientifically by recording an ETW trace using UIforETW with GPU tracing enabled. This gives me three crucial bits of information:

1. UIforETW logs custom ETW events for all user input so I can see exactly when the right-mouse button is pressed and released.
2. Microsoft-Windows-Win32k logs information about Window in Focus changes so I can see exactly when a window gains focus.
3. The GPU tracing lets me see exactly when GPU activity occurs so that I can tell when the menu is drawn.

From the mouse-up event to ShellExperienceHost.exe gaining focus is approximately 120 ms.
From the focus change to the large spike of GPU activity which I believe represents the menu being rendered is approximately 110 ms.

Thus, in the particular event that I am looking at the total latency is 230 ms. This is fairly consistent across multiple traces, multiple clicks on the same entry, etc.

I can supply ETW traces and more analysis details if there is interest. The slowdown is mostly from CPU activity. I see 139 ms of CPU consumed in ShellExperienceHost.exe, 102 ms in RuntimeBroker.exe, 40 ms in explorer.exe, and lesser amounts in System and dwm. There is not enough parallelism to make this 200+ ms of CPU time happen quickly enough.

Sampling data says:

• About 53 ms is spent in JumpViewUI.dll!JumpViewUI::JumpListViewModel::UpdateContents. Seems excessive.
• Another 17 ms is spent in Windows.UI.Xaml.dll!CCoreServices::NWDrawTree
• Another 19 ms is in Windows.Internal.Shell.Broker.dll!TileIconLoader::GetBitmapFromExtractIcon, which includes loading a DLL
• Another 13 ms is in StartTileData.dll!winrt::WindowsInternal::Shell::JumpList::Broker::implementation::JumpListShellItemData::JumpListShellItemData, which includes time spent in shlwapi.dll!IShellFolder_GetDisplayNameOf
• There were 27 samples in explorer.exe but they defy categorization - it's not clear what it was doing

[randomascii]

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.

[randomascii]

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.

[randomascii]

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.

[randomascii]

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

[Foda]

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.

[randomascii]

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.

[asklar]

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 :)

[bitcrazed]

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

[Foda]

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.

[randomascii]

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

[ghost]

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

[bitcrazed]

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

[antiufo]

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

[randomascii]

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/

[justanotheranonymoususer]

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.

[orcmid]

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

[rastamanx]

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

[randomascii]

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.

[rastamanx]

Hi Bruce. Thank you so much for your reply, and for your offer to help me analyze the slow down issue. I will download and run the UIforETW Trace, And adjust the configuration parameters for your recommendations. would you like me to run one trace with the Suspect Google DLLs enabled, and another trace with the suspect DLLs disabled (for comparison)? Also, I’m not sure how big the trays log file will be, or how to share it with you… But I’m assuming I can either email it to you directly or share it in a dropbox folder. If you have any preferences, please let me know. Thank you again for your assistance. 🙏💛 Regards, Dean Wolf

…

------------------ Dean E. Wolf Intellectual Property Attorney | Corporate Counsel law@ipmls.com • 510.290.8866 www.WolfIP.com **Typos courtesy of iPhone** On Oct 16, 2020, at 10:52 AM, Bruce Dawson <notifications@github.com> wrote:  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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEAN4KTBZFZMZPAPUTMQSTSLB25LANCNFSM4QIIIPEQ> .

[randomascii]

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.

[Poopooracoocoo]

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.

[bitcrazed]

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.

[randomascii]

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.

[bitcrazed]

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.

[JasonWei512]

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

[randomascii]

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

[Fasteroid]

Having this problem again as of KB5003637 and KB4023057.

[bitcrazed]

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.

[Eli-Black-Work]

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

[randomascii]

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

[Eli-Black-Work]

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

[randomascii]

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

[graememeyer]

It’s a pretty viciously dumb response as well because how could they know how many people have tried to submit longer feedback requests and either given up or had to cut out all the detail to make it fit. - Graeme

…

________________________________ From: Bruce Dawson ***@***.***> Sent: Thursday, June 17, 2021 4:03:42 AM To: microsoft/Windows-Dev-Performance ***@***.***> Cc: Graeme Meyer ***@***.***>; Manual ***@***.***> Subject: Re: [microsoft/Windows-Dev-Performance] Jumplist performance is still too slow - 200-250 ms to display a menu (#37) Good news: somebody already filed a feedback request for allowing longer feedback requests - https://aka.ms/AA1vcsz<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAA1vcsz&data=04%7C01%7C%7C311cfa4cdc23411c85fe08d9313c8394%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637594958234461387%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=b57x0uikMK2GIs9ugRxcgSNUJaxNuDgPC9GuQV87x4k%3D&reserved=0> 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... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FWindows-Dev-Performance%2Fissues%2F37%23issuecomment-862879937&data=04%7C01%7C%7C311cfa4cdc23411c85fe08d9313c8394%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637594958234471349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=09gOskFPxNpA2TM0vQ8gNXnPod0yAug5bybWRNdCiS0%3D&reserved=0>, or unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA573CWHCSMUBI5GWRA2V7DTTFQY5ANCNFSM4QIIIPEQ&data=04%7C01%7C%7C311cfa4cdc23411c85fe08d9313c8394%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637594958234481304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ABygoBuwmUYg3XePSnv7VIxVcyrbN1Wx0ji9dfWadUk%3D&reserved=0>.

[Poopooracoocoo]

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 😂😂😂

[Eli-Black-Work]

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