Big profiler dumps are impossible to inspect

[FluffyDiscord]

Unfortunately the Profiler debug page/dumps have performance issues. It takes several dozen seconds to load, then any kind of interaction takes seconds (tooltip, hover, click, etc)

I have fairly powerful PC (16 threads ryzen 4800HS, 32gb ram, kubuntu 20.04)

[butschster]

Hi! In the latest version we added threshold setting in the right corner. You can try to play with it. I think we will try to optimal value for threshold and also try to optimize rendering

[FluffyDiscord]

Hi! In the latest version we added threshold setting in the right corner. You can try to play with it. I think we will try to optimal value for threshold and also try to optimize rendering

I am using the rc10 version. I can't see threshold setting (? maybe I am blind).

[butschster]

Hi! In the latest version we added threshold setting in the right corner. You can try to play with it. I think we will try to optimal value for threshold and also try to optimize rendering

I am using the rc10 version. I can't see threshold setting (? maybe I am blind).

I'll check it.

[butschster]

@FluffyDiscord Hi!

I've just rebuild last image rc10 and now it contains latest version of frontentd. I don't know why, but in some cases it pulls previous release for latest tag(

[Kreezag]

@FluffyDiscord Hi!

Could you check your dump with the latest version of buggregator?
Buggregator image rc10 already include threshold feature.

[FluffyDiscord]

@butschster @Kreezag I just tried the re-released rc10 image. I can confirm that the UI has changed indeed.

The profiler still has the same issues. I do not mind that the graphs load some time, but I have issues with the UI being unresponsive (clicking, scrolling, JS hovering, basically any interaction). Even a really small dump takes seconds to load, then seconds to render, then freezes randomly whenever I want to do anything even on a rather modern/powerful PC, I can't imagine how low end laptops fare - video showing the situation.

example.mp4

Could the loading/processing stuff be, perhaps, moved to service worker thread? The graphs could be drawn in canvas and tooltips could be as html as overlay (as do for example some map implementations in JS, they are quire performant). Side menu list should really implement virtual list (this probably is the real culprit of all of this lag). Its rendering thousands or nodes, even though user sees only 30 of them.

Also I am not sure what the usage for threshold is, or rather what it should do. Going blindly (I guess its still WIP as there are no docs for it?), I am expecting it filters out any nodes that have percentage usage below the set value, yet it doesn't seem to be the case. Can someone please explain what is actually does.

[butschster]

Hi @FluffyDiscord!

Please try the newest version v1.0-rc14. In this version, @Kreezag changed the old graph renderer to a new one. I tested it, and it seems to be 10 times faster without reducing performance. I'm waiting for your thoughts.

[FluffyDiscord]

@butschster I could not test the new release on the same machine (not at work right now), so here are my thoughts, running on my personal pc (5800X3D, 32GB RAM, RTX 4090, kubuntu 23.10, kernel 6.5.7)

• the initial dump load still takes a lot of time, it's usable, but annoying
• the graph/nodes are now changing/rendering within one second, huge improvement
• the left side is still the same and unusable, do not render all nodes, please use virtual list, I have mentioned this before
• graph/node tooltip position does not keep the tooltip within the view, overflowing and making the page scrollable (seen in video bellow), mildly annoying, since I have to move the view/node to see the whole tooltip

difference.mp4