Thread list updates uses too much CPU resources

[Vort]

When I load program with 27 threads, Very Sleepy starts using 10% of my total CPU resources (4 cores) for thread list refreshes.
I expect that it may be problematic to update this list for programs, which use even larger amount of threads.
I propose to add option, which lowers refresh rate for thread list, it may help in such cases.

[CyberShadow]

I understand that this only applies when selecting the process and threads to profile, and not during actual profiling (or viewing the results), right?

If there is indeed a performance problem that scales at least linearly with programs' thread count, lowering the refresh rate will only help with some range of thread counts.

Some things that could be done:

• Investigate why Very Sleepy uses so much CPU for this case. If it's something that could be optimized, that would probably be a better solution.
• Schedule thread list refreshes relative to the end of the previous refresh, instead of the start. That will ensure that the CPU is idle at least some of the time.
• Add a limit to the number of threads that Very Sleepy looks at.

[Vort]

I understand that this only applies when selecting the process and threads to profile, and not during actual profiling (or viewing the results), right?

I made 3 additional tests:

1. Profiling of high activity thread - usage was 8-10%.
2. Profiling of low activity thread - usage was 4%.
3. Viewing results - usage 0-0.3%.

Investigate why Very Sleepy uses so much CPU for this case. If it's something that could be optimized, that would probably be a better solution.

Here are two most hungry functions (collected from thread list updates with i2pd.exe process opened):

I used verysleepy-0.91.exe, tested with program https://github.com/PurpleI2P/i2pd, built with MSYS2 and Clang, on Windows 7.

[CyberShadow]

Here are two most hungry functions (collected from thread list updates with i2pd.exe process opened):

This looks reasonable to me, symbol resolution is bound to be the most complicated part of profiling (even though at that point we're just peeking).

Some ideas on how to improve on this:

• Cache symbol resolution, though this will only help applications which spend most time in one place.
• Add a checkbox which disables symbol lookup when previewing the thread list.