-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Excessive CPU and RAM usage #29
Comments
The tracebacks do not happen during operation, but after you close the app with the "X" button, as far as I can tell. My total wild-guess hunch is that probably your GUI is spamming the graphics stack by refreshing way too often (the dev could probably throttle the labels + charts updates? If they update every milisecond or so, that would be very wasteful), and/or spamming glib signals, or something like that. I haven't looked at any code, this is just a guess. More objectively, the developer can confirm whether that hunch of mine is true or not based on what we can see from profiling with Sysprof 46 (devs, let me know if you need the sysprof capture file), as shown below. Flame graph of most frequent/expensive function calls: Graphics marks (solid blocks like that seem to lead credence to my hypothesis that you are spamming the graphics stack): |
Ah, you're right about the tracebacks happening after closing the application. Sorry, I didn't realize that's when it actually occurred. Everything else you said is way over my head. I'm not "doing" anything other than running the program. |
With "you" I meant the developer generally. Another quick hunch on my theory above: whatever is happening, it's causing about 62 thousand function calls in the app over the span of 29.6 seconds. That's a bit over 2000 function calls per second, which seems very wasteful, I don't see why you'd need more than, say, 60 calls per second on a 60 Hz monitor based on vsync. Even on high refresh rate monitors at 240hz, it would still be ten times less than what is happening now. |
Just to be sure, as I narrowed down the tracebacks to occurring only outside of the flatpak version and causing incorrect measurements (see issue #37), I have retested the performance issue here with the flatpak version, and it still happens; 100% single-core CPU usage, so the function calls spammage performance issue itself is apparently not caused by the tracebacks (and it happens even before the upload test occurs anyway). |
This is a fine GUI, however as the title says, it's very intensive. I'm using 1.2.1 via my speedtest-librespeed AUR package on Manjaro GNOME (unstable branch).
The speedtest succeeds, however the terminal output seems to complain while it runs:
The text was updated successfully, but these errors were encountered: