Why is the start menu so slow and unreliable?

[SledgeNZ]

Not a bad design, it just hasn't been optimised. MS can allow the start screen to run unsuspended however they obviously haven't optimised the system to do this yet. By all means put in feedback saying 'It's slow' and it'll get the attention it deserves. When it's running unsuspended it's snappy on my systems.

 

Xaml in itself isn't slowing the menu down, they're continuing to optimise this and the app itself is compiled down to native.

 

It does have things like application insights running which is logging what you are doing so they can see how it is or isn't being used.

[georgevella]

- its a separate process, not part of explorer.exe (which is always running)

- its in XAML (all XAML/Metro apps have a big performance penalty - just try to run the new calc and see how long it takes to load)

Unless MS messed up the scheduling, having separate processes running doesn't have any effect at all on performance.  Secondly, the start menu itself is not a separate process - in fact I've crashed it a few times and the whole explorer shell drops - the reason you're seeing the link between the startmenu and searchui.exe is because MS moved the search logic to a separate process, thus stopping long queries from affecting the start menu performance.  This is all conjecture so correct me if I'm wrong. Lastly, XAML and WPF should be GPU accelerated so I'm gonna peg your performance issues on GPU drivers.  

[SekaiStory]

Ok, so -

 

- its a separate process, not part of explorer.exe (which is always running)

- its in XAML (all XAML/Metro apps have a big performance penalty - just try to run the new calc and see how long it takes to load)

- the actual app itself has a lot of changes

 

The first 2 reasons are enough reason to worry, even if they can fix these issues, its never going to be instant to open like before. Can't really say its a good decision, esp on lower en d hardware the difference is easily noticeable. 

 

And to those who keep saying 'its not done yet', give it a rest. 6 months of updates and even the most basic issues haven't been fixed, compared to the very first TP there's hardly anything improved.

 

Can I know your specs? Start menu (and calculator app) run/open blazingly fast here, and rarely ever crashed.

[hagjohn]

I may not like it but I've never had an issue trying to open it.

Ok, so -

 

- its a separate process, not part of explorer.exe (which is always running)

- its in XAML (all XAML/Metro apps have a big performance penalty - just try to run the new calc and see how long it takes to load)

- the actual app itself has a lot of changes

 

The first 2 reasons are enough reason to worry, even if they can fix these issues, its never going to be instant to open like before. Can't really say its a good decision, esp on lower en d hardware the difference is easily noticeable. 

 

And to those who keep saying 'its not done yet', give it a rest. 6 months of updates and even the most basic issues haven't been fixed, compared to the very first TP there's hardly anything improved.

 

The new calculator opens up fast for me.. within 1 or 2 seconds.

[Defcon]

I have an older laptop (C2D) and Win 10 seems much slower on this, I suspect a big part is due to Metro apps being so slow. On my desktop which is much newer (Core i5) the delay is much less but its still noticeable.

 

I suspect Win 10 won't really work that well on lower end hardware and MS is still targeting it at newer pc's and tablets/phones. They know very few people with Win 7 or older will bother to upgrade.

[Dot Matrix]

It's slow and buggy because the code is still in flux.

[fordcom]

I have been facing same issue since upgrading to build 10074. It's on and off. As I'm tying this post, my start menu is not working for an unknown reason. Hope is fix in the next preview release. So annoying sometimes to restart you PC several times to get the start menu to work.

 

Sometimes disabling the search on the  task bar seems to fix the issue.

[JakeB]

It was supposed to RTM in June/July last I heard....

 

I'm hearing that RTM is a thing of the past. I read they are going to do it sort of like the setting in the Technical Preview of FAST (Insiders program) or SLOW (Public). The OEM's will be in the fast group which will be like the RTM but they insiders and OEM's will have the option to upgrade.

[Defcon]

It's slow and buggy because the code is still in flux.

Enough with this excuse for every single complaint!

Even after RTM the same excuse can easily be used since it's not going to be a final OS.

[Guest]

Why is Start Menu a seperate process? I don't get it.

 

Because it is actually sort of an Universal app.

- its in XAML (all XAML/Metro apps have a big performance penalty - just try to run the new calc and see how long it takes to load)

 

That may have been correct with .NET 3 or something similar, back when WPF was first coming to life, but not with the XAML that is present in Windows 10. It is XAML, but it actually compiles to native code. The reason it is bad at the moment is because it is not polished at all, they have not done a feature freeze and have not had their usual bug fix sprint before release yet.

[adrynalyne]

It was supposed to RTM in June/July last I heard....

Yeah and the public builds are a good 30+ versions behind what MS has internally.

[adrynalyne]

I have an older laptop (C2D) and Win 10 seems much slower on this, I suspect a big part is due to Metro apps being so slow. On my desktop which is much newer (Core i5) the delay is much less but its still noticeable.

 

I suspect Win 10 won't really work that well on lower end hardware and MS is still targeting it at newer pc's and tablets/phones. They know very few people with Win 7 or older will bother to upgrade.

 

Or...you could do the smart thing and adjust visual features according to your hardware. It won't fix some things obviously due to debugging code still running and tweaks still needing to be made. It will increase your performance however, assuming it is currently functioning in Windows 10, which is still not even near RC quality.

[BinaryData]

Hmm..

@ OP

Have you thought about posting your PC specs, so people can get a basis of what the "minimal" requirement is to run it? My rig at home is a bit sluggish.

CPU: 2.66Ghz
RAM: 4GB
GFX: 560 GTX
HDD: Enterprise Level 10K RPM 300GB Raptor Drive

 

According to the Google searches, my rig should run it fine, but it doesn't.

[FunkyMike]

Unless MS messed up the scheduling, having separate processes running doesn't have any effect at all on performance.  Secondly, the start menu itself is not a separate process - in fact I've crashed it a few times and the whole explorer shell drops - the reason you're seeing the link between the startmenu and searchui.exe is because MS moved the search logic to a separate process, thus stopping long queries from affecting the start menu performance.  This is all conjecture so correct me if I'm wrong. Lastly, XAML and WPF should be GPU accelerated so I'm gonna peg your performance issues on GPU drivers.

 

And this right here is the exact reason on why this new XAML based Start Menu is currently so unstable. In effect it goes counter to what MS was trying to achieve with TDR in the prevention of Graphics Drivers taking down vital Windows functional.

 

Because now when a driver crashes or is poorly programmed like in AMDs case for switchable laptops .. it will take out the Start Menu and all the XAML apps in the process without any hope for recovery.

 

Once such crashes happen ShellExperienceHost.exe goes into an endless state of loop and simply does not manage to start.

 

When everything was neatly integrated into one place/ process .. the drivers and the system knew its place.

 

Now you have several processes that have to be adjusted to accommodate the graphics drivers.

 

Then you need to take into account laptops switchable drivers states where XAML needs to follow the change from Intel to AMD.

[Defcon]

Yeah and the public builds are a good 30+ versions behind what MS has internally.

Do you know this for a fact or is it just speculation?

 

There has been very little progress between the TP back in Nov and what we have today, it certainly does not bode well.

[Ian W]

Do you know this for a fact or is it just speculation?

 

There has been very little progress between the TP back in Nov and what we have today, it certainly does not bode well.

The Start menu was not even based on XAML back in November.

[FunkyMike]

The Start menu was not even based on XAML back in November.

 

Just goes to show that such a drastic change prior to RTM without decent testing is sure to backfire and get noticed by the people for which it will perform poorly.

 

There is a reason that the Server edition doesn't have the XAML menu... just saying.

[Ian W]

Just goes to show that such a drastic change prior to RTM without decent testing is sure to backfire and get noticed by the people for which it will perform poorly.

Thank you for stating that the change to XAML was a drastic change; this is, in fact, why I mentioned it. Contrary to Defcon's assertion, more than "very little progress" has been made since the Technical Preview in November

[FunkyMike]

I believe we are all discussing it with the best intentions talking about the same problem but through different lenses.

 

Maybe we interpret progress critical to our own situations differently and maybe Defcons issue also relates to XAML performance in general..

 

I have written to an MS rep who concerns himself with graphics driver issues such as these that affect Windows 10. 

 

Am waiting on the feedback but this situation is a bit too close for comfort considering that Windows should be out soon.

[Defcon]

Thank you for stating that the change to XAML was a drastic change; this is, in fact, why I mentioned it. Contrary to Defcon's assertion, more than "very little progress" has been made since the Technical Preview in November

[Ironman273]

Just been perusing this thread.  My start menu has been close to useless since the start of the tech preview.  I was used to hitting the windows key and typing the program I wanted and it would come up immediately.  Now, half the time the start menu doesn't even appear when I press the windows key. Once it does, however, it'll work for a bit pretty well.

 

CPU: Intel i7-3770 @ 3.4GHz

RAM: 12GB

GPU: Radeon R9 270X 2GB

[Ian W]

The internal tech is another matter. Whether or not it's better for users is what defines progress as far as most users are concerned I'd think.

I would be inclined to think so as well, but your previous responses suggest something else. You have stated

[adrynalyne]

Do you know this for a fact or is it just speculation?

 

There has been very little progress between the TP back in Nov and what we have today, it certainly does not bode well.

Lets see.. latest public build is 10074.

 

Front page:

 

https://www.neowin.net/news/gallery-windows-10-build-10114-start-menu-gets-refined

 

10114 - 10074 = ?

 

40 builds. No speculation on my part.

 

And yes...there has been much progress since November.

[adrynalyne]

 

Ok, so -

 

- its a separate process, not part of explorer.exe (which is always running)

- its in XAML (all XAML/Metro apps have a big performance penalty - just try to run the new calc and see how long it takes to load)

- the actual app itself has a lot of changes

 

The first 2 reasons are enough reason to worry, even if they can fix these issues, its never going to be instant to open like before. Can't really say its a good decision, esp on lower en d hardware the difference is easily noticeable. 

 

And to those who keep saying 'its not done yet', give it a rest. 6 months of updates and even the most basic issues haven't been fixed, compared to the very first TP there's hardly anything improved.

 

 

http://screencast.com/t/BnsXnxoy

 

This is on a 3 year old Mac Mini.

[FunkyMike]

I would be inclined to think so as well, but your previous responses suggest something else. You have stated