"Show recent Metro apps" delays menu opening

[Gittyperson]

Enabling this option, causes a small (about 1 second) but noticeable delay when opening the main menu. Does not seem to occur on the Classic 1-column style (or becomes unnoticeable), confirmed on the other two styles.

http://www.classicshell.net/forum/viewtopic.php?f=7&t=4688&p=19679#p20677

[XenHat]

Known issue. Recent items are fetched on menu opening. Could be fixed with a periodic updating but that causes other issues.

[XenHat]

Not sure what the actionable fix could be. @ge0rdi, @ibuprophen1 ?
We could write a service to update these things in the background instead of on menu open... I've no idea how to do that, however.

[AveYo]

Cache them on start and only refresh them on "Highlight newly installed programs"?

[Ibuprophen]

I'm thinking that this might be tied to one of the default delays within the menu settings...

I'd have to take a look and see.

~Ibuprophen

[XenHat]

I'd have to take a look and see.

Go ahead, no need to ask us for this 😄

[Ibuprophen]

My apologies for the delay @Gittyperson!

This is one of those "I've Seen/Done it Before" situations and, after performing a handful of the Delay Multiplier settings, I just can't remember which one it was...

One of the following 3 images are where the settings you are looking for are located within...

general-behavior-tab
main-menu-tab
menu-look-tab

... and, within them, you'll locate 2 different types of these called the "Speed" and the "Multiplier" with a 2-3 digit number at the end ":xx" & ":xxx". The larger the multiplier number is, the faster (and vice versa).

These numbers take effect in real-time. This means that if you change the number, and then select another spot within the same menu (basically taking the attention from that setting you had changed), you can open the Start Menu (with the settings window still open) and you'll see the results of your change.

Please keep in mind that, for my personal custom settings that I use, did take me some time to figure out what, where, etc... worked for me.

Please Note: There's various settings that you'll see on those images that may differ from yours because they are NOT the default settings. They reflect my personal ones. I just decided that it would be a pain to default them all just to provide the example screenshots.

Please let me know if you have any questions and I'll do my best to help you out.

~Ibuprophen

[Ibuprophen]

By the way... @ge0rdi, @XenHat & @coddec are more than welcome to use the images & information from my (above) post if you want! 😨

~Ibuprophen

[AveYo]

Dude.. that's not helpful at all. OP talks about the delay you see when using minimum values in the settings - of course you won't feel it if you delay all the menus for 4 freaking seconds..

The actual issue is with refreshFlags for MetroLinks but can't compile it myself atm to experiment with.

[Ibuprophen]

This issue was opened by @Gittyperson and, had not followed up with it for almost a year, it looks like this issue has been resolved or the individual found a work around (or something).

I'm going to close this issue based upon the above...

~Ibuprophen

[Gittyperson]

As mentioned in the title, issue is related with the Metro apps setting, and not any delay settings. Nothing has changed as far as I know (4.4.131) and this fairly minor issue remains.

[Ibuprophen]

It looks, to me, like this is something that requires a Customization of a setting based upon your personal preferences.

If I'm correct, then it's really not a software issue rather than a personal preference.

Basically, the default settings of the software will require the individual to make changes for personalized use. This is why those options are available within the software for the individual to change them if necessary.

Please correct me if I'm wrong.... 😱

If, in fact, this is an issue with the actual software itself, please elaborate as I can reopen this issue.

If an issue is found that is reflected by multiple individuals, then this would prompt the developer(s) to take another look at it for a correction.

~Ibuprophen

[Gittyperson]

I've described it as clearly as I could on the first post. The slight delay is just the symptom. The delay settings or any other user preferences are not related.

1. Select one of these two styles: "Classic with two columns" / "Windows 7 style"
2. Open the Start Menu with the mouse button or the Win key.
3. Toggle the "Show recent Metro apps" setting on/off, and compare the speed with which the Start Menu opens.

There will be a small, but noticeable additional delay when "Show recent Metro apps" is enabled.

[Gittyperson]

Confirmed again now with the default settings. I am not aware of a setting that adjusts the delay of the main menu appearance (not submenus/subfolders).

"Show recent Metro apps" is the culprit here.

[Ibuprophen]

Thank you very much for the clarification! :-)

I'll reopen this and see if I can reproduce this myself as well.

Maybe @coddec, @ge0rdi or @XenHat can provide some clarity with this.

~Ibuprophen

[Ibuprophen]

@Gittyperson, I tried to duplicate this the best way I could based upon the information within this issue and I could not.

I actually tried to duplicate it 3 times in a few different ways too...

Is there anyone else who can help provide some additional guidance here?

~Ibuprophen

[Gittyperson]

Ok, thanks for trying. Let's see if someone else gives it a try. Note that this delay is very subtle and it's only about opening the main menu from the start button, not subfolders or anything else.

[Ibuprophen]

@Gittyperson, are you using "Classic Shell" or "Open Shell"?

I'm asking to be sure...

Only because I've realized that issues have been submitted reflecting the older "Classic Shell" software and this GitHub Repository is for the "Open Shell" software.

Thanks a Bunch! 👍

~Ibuprophen

[Gittyperson]

It happens both on Classic Shell and Open Shell. Using the latter, clean install (no upgrade from CS).

[pfofi]

I can confirm Show recent Metro apps is the culprit here under Main Menu -> Show recent or frequent programs. The option Frequent programs above it also has to be enabled.

There is a noticeable delay when opening the Start Menu and CPU usage jumps for a moment.

For me, disabling that option is actually a viable workaround. Metro apps can still be found via search.

[klepp0906]

Yes. This is wreaking havoc on my experience. If “frequent” is enabled (preliminarily doesn’t seem to affect “recent”) it hangs for about 5 seconds on my pc while it spins up my external hard disk.

Only way around I’ve found is disabling frequent (which is my preferred like most i imagine) or shutting down my external which then makes the delay more like a second or two like the OP as opposed to much longer while it spins up a sleeping drive for who knows why :p

[klepp0906]

fwiw i opened up the start menu and the frequents list displayed 1 windowsapp. I removed it from the list (imagine thats temporary until its re-used often enough to make it back) and the issue with spinning up my external is gone.
so it definitely seems linked to uwd stuff appearing on that list.

still cant figure why its spinning up my external drive (or if it actually just spins up ALL drives for some reason) hence causing a big ole soft hang on my side.

either way, even without the spinning up of my external - its substantially faster with either "show frequent apps" changed to "recent" or with disabling the "show recent metro apps" portion of it.

until a fix is discovered im gonna go with disabling the metro apps portion as i find showing the frequently used apps much more useful than the recent.

[McKay42]

Can also confirm, disabling "Show recent Metro apps" decreases the delay a lot.

Previously I would start typing directly after hitting the windows key, and the keystrokes were ignored because the menu had not finished opening yet. Coming from Windows 7 muscle memory.

On the native Windows 7 start menu there was 0 delay (1 frame at most), but I'm very happy with disabling recent metro apps here (no more lost keystrokes).

With enabled "Show recent Metro apps", delay is 8 frames at 60 fps = 128 ms +-16 ms:

(Notice how the start button immediately updates, but the menu lags behind.)

With disabled "Show recent Metro apps", delay is 3 frames at 60 fps = 48 ms +-16 ms:

[blackcrack]

could it not be possible it's due to Win10 and its response time ?
the listing of the WinNT 10 own it's *imho* also a bit womby (Wombat)

best regards
Blacky

[nfroggy]

I have also been experiencing this issue. Disabling the checkbox reduces time to open the start menu from about half a second to almost instant.

[bonzibudd]

Is it possible that this can be traced down using Open-Shell's logging feature, or some other method?

I've tried to see if any other option has an effect on this, and I have found none. I tested all of the menu delay options like @Ibuprophen suggested, and I was not able to create any positive or negative effect on the initial loading time. Additionally, it seems like this issue is lesser with a faster computer, and amplified by a slower one (However, I haven't measured the time, so it could be placebo). I will try to find the version of Win10 which this issue originally appeared on, so hopefully this can help track down a change in Windows which caused this. My guess is somewhere between 2016-17.

Something that I found strange is that this issue occurs regardless of how many frequent programs are set to show. Even forcing the "All Programs" list to show automatically retains the delay. Disabling frequent programs altogether or switching to recent programs does fix it, but this isn't a solution for some people.

I will do some investigating later to see if I can track down which version caused this issue.

[ge0rdi]

Is it possible that this can be traced down using Open-Shell's logging feature, or some other method?

You can try to create ETW trace from the issue:

• Make sure you have latest official build installed (so we can get proper symbols)
• Run wpr -start GeneralProfile from elevated admin console
• Replicate issue (I guess just open Start Menu)
• Run wpr -stop trace.etl from elevated admin console to save trace
• Upload trace somewhere and provide link to it

Note that ETW trace may contain sensitive information from your machine (it basically traces what all processes are doing).

Additionally, it seems like this issue is lesser with a faster computer, and amplified by a slower one

On decent machine with SSD disk it is very likely you won't notice any delay (I can't see any significant delay on my machines).

[klepp0906]

fwiw i have a very fast machine on an nvme ssd. admittedly some of the shortcuts that populate the list at times do come from items on mechanical disks however.

[ge0rdi]

admittedly some of the shortcuts that populate the list at times do come from items on mechanical disks however.

In such case the disk may be sleeping when Open-Shell is accessing file on it. Thus it will have to wait till disk wakes up (which can take several seconds).

[klepp0906]

that would be a much more pronounced/protracted delay. (plus you can hear these monsters spin up).

Its not accessing the items its simply displaying the menu which would have the shortcut icons cached i would think?

I will say i disabled the feature quite some time ago and dealt with recent items instead/since. I'll repay it another visit in the near future and see if I can re-test some variables to provide a bit more info. (all i can do as a user).

In all fairness it could have improved in the half a dozen iterations since then.

[bonzibudd]

@ge0rdi

trace.etl

This is from newly installed virtual machine. I clicked on Start button once with the default settings, then again with recent Metro apps disabled. The delay was less than on my 2 main machines, but still significant.

[ge0rdi]

It seems the delay is caused by this line in CMenuContainer::GetRecentPrograms.
According to trace each call to SHCreateItemInKnownFolder adds ~13ms delay and there are 10 such calls.

It basically tries to resolve name of Modern app and discards records that cannot be resolved or start with @{ (whatever that means).

Not sure if the check is really necessary. I'd try to find some replacement or basically just remove it completely.
Will create PR so you guys can check whether it will help in your cases.

[ge0rdi]

Guys, please, try build from PR #460.
It should make menu opening faster.

[bonzibudd]

@ge0rdi

Yep, it's fast. Will be even better for mechanical drives.

[Gittyperson]

I'm not sure if there's an improvement (if there is, it's very small) but the delay is still noticeable here. (old PC, SSD on SATA 2).

[bonzibudd]

@Gittyperson

Strange. For me, the delay is now identical w/wo recent metro apps on. It might be worth completely uninstalling and re-installing once again. I would also choose "Clear cached information" and then "Reset all settings" and see if that helps.

If none of that helps, you should make an ETL file like I did. That would help determine the issue more easily.

[Gittyperson]

I cleared everything, uninstalled, restarted and reinstalled. Currently on default settings. Perhaps there's a small improvement, but delay is still there. Menu opens instantly only when disabling recent Metro apps. I'll try the ETL tomorrow.

[bonzibudd]

Very strange. Just to make sure, is the menu settings reporting version 4.4.153?

[Gittyperson]

Yes, 4.4.153. Revisiting my first post, I had forgotten this issue does NOT occur on Classic style. Just re-confirmed this. Delay only appears on the other two styles. Perhaps that's something to investigate?

I can send the trace if necessary but I'll need an email or similar, I'd rather not post it here.

[bonzibudd]

Ok. You should get in touch with @ge0rdi . Hopefully he can provide a direct way to upload the file.

About the Classic style, this is because the default setting is to show "Recent" programs, instead of "Frequent."

[ge0rdi]

@Gittyperson
Its a shame that Github doesn't have a way to share sensitive content with project members :(

Feel free to upload ETL to some cloud storage and send me a link to ge0rdi (at) gmx.com .
I'll try to have a look.

[XenHat]

if it's really sensitive, you can use gnupg. keybase.io provides a decent interface

[ge0rdi]

@XenHat
Thanks for the tip.

I just meant that it will be great if there will be some way how users could share such information with project members on Github without exposing their private e-mails/keybase.io id/etc.
This would be great for providing crash-dumps, ETW logs and other kind of debug information.

[Gittyperson]

Ok, just sent it. Includes both 4.4.152/3 trace files, not sure which one you preferred. Same as bonzibudd: clicked on Start button once with the default settings, then again with recent Metro apps disabled.

[ge0rdi]

@Gittyperson
You have used build from different PR.

Please, use build from PR #460.
Here is direct link to installer.

Note that these builds from pull-requests are unofficial, so they are not meant for daily usage. Just for checking whether given fix/change works as expected.

Once PR will be merged to master, there will be official build created that can be downloaded via Latest nightly build link.

[Gittyperson]

Thanks, took me a while to locate an installer there... and I got the wrong one.

With a quick test, I'd say there's a 90% improvement. 👍 A barely perceptible delay still remains, but on newer PCs it probably won't be there at all. Many thanks, ge0rdi!

[ge0rdi]

Change is now merged to master.
Please, use latest nightly build (4.4.154) that contains it.