Taskbar Latency and Kernel Calls | Hacker News Reader

Taskbar Latency and Kernel Calls

randomascii.wordpress.com

55 pointsnikbackm13 comments

I really appreciate your efforts on this.

I am fairly certain that I experience the same latency issue with right-click context menus in Windows Explorer as what you have described.

I was hopeful that the recent acquisition of a new machine with a fresh WIN10 install on it would provide me relief from this issue -- but the situation is unchanged with the fresh install.

Your research shows me that the underlying situation and cause is hardly something that "I am imaging" -- this is an ugly piece of mis-performant code.

Note that my blog post now lists two solutions that users can implement. Check them out. They make a big difference.

Any idea how to do something similiar on Linux? I'm using Plasma 5 on Arch Linux and from time to time I'm seeing mysterious hangs (seconds to minutes) on the Plasma UI - CPU profiling is probably useless and for me it looks like perf record is just way to broad and the hangs are not due to CPU churning but probably something else (scheduler or locks - I have no idea), I'm not a dev but it would be nice to be able to at least produce a proper bug report and searching the root cause.

I have similar issues with Plasma and definetly can say it is a graphics card/hardware problem which is intertwined with the graphics driver. Plasma is very heavy on graphics effects. You might want to change details (like having shadows or transparency) in the settings to see if it changes something.

Brendan Gregg has a lot of one-liners for recording perf data, however none of them give the "record everything and analyze it later" flexibility of ETW, as far as I can tell.

Perf also lacks a powerful UI like WPA. But, perf is pretty amazing in its own ways.

LatencyTOP might help you track down the cause.

http://www.ubuntugeek.com/latencytop-measuring-and-fixing-li...

Depending on your CPU, you might be able to use SATT: https://github.com/intel/satt

This looks great! Thanks for the hint!

Too bad Microsoft is too busy with integrating ‘telemetry’ spyware and parading their ‘wasting your resources isn’t our problem’ mindset to fix these obvious issues that have been part of the Windows experience for decades now.

Ironically I suspect it is the lack of telemetry for this action that allowed this performance problem to linger this long. If Microsoft had this action Perftrack instrumented and had their usual 100 ms performance target then they could grab ETW traces from the field and would have figured this out.

Instead they appear to have been dependent on anecdotal evidence and nobody taking responsibility.

Or maybe I'm wrong. Maybe this action was instrumented but was then ignored. That would be sad.

Perftrack reference: https://channel9.msdn.com/Blogs/Charles/Inside-Windows-7-Rel...

If they’re missing basic problems like this the solution is not more telemetry, the solution is qa. Not even better qa, just start with basic qa. Because right now they’re just doing nothing and treating their paying customers as alpha testers. I don’t quite understand why people accept it.

Some of the slowdown should have been noticed by QA. But most of this slowdown occurs when you have used your machine for long enough to accumulate 4 MB of File Explorer history. Telemetry is the perfect tool for catching this sort of real in-the-field problem. More QA is also important.

> I don’t quite understand why people accept it.

alas understanding is completely removed from the equation.

Why does the average person buy a computer ?

my small sample say "no more post office, everything is online, so I .. need something"

Reply on news.ycombinator.com