GNOME Bugzilla – Bug 784216
GNOME Logs are slow
Last modified: 2017-10-27 12:19:22 UTC
I quite like how this application works, but it becomes painfully slow when going deeper down the log. Do you know about this or is this only mine problem? If so, can I get some debug information, that would help you improve the performance? Thanks.
To solve this, maybe GNOME Logs could implement some multi-threading mechanism to prefetch the upcoming journal entries in the model or cache them to be shown in the events list later on. Due to this, scrolling can be made smooth when going deeper down the logs.
Well I don't really understand why is it slow in the first place... I mean.. The logs are basically files and when we go deeper, we simply traverse through file and parse it into items.. But when I scroll whole one thread is running on 100% (I run on Core i3 540@3GHz) - it's probably doing some unnecessary work and would be worth a look through profiler.. Maybe calls to GTK during creating items are killing the performance?
(In reply to David Novák from comment #2) > Well I don't really understand why is it slow in the first place... I mean.. > The logs are basically files and when we go deeper, we simply traverse > through file and parse it into items.. > > But when I scroll whole one thread is running on 100% (I run on Core i3 > 540@3GHz) - it's probably doing some unnecessary work and would be worth a > look through profiler.. Maybe calls to GTK during creating items are killing > the performance? Yes, might be a possibility. Would need to examine GNOME Logs through a profiler such as sysprof.
@David Thanks for the report. You're not alone with this problem. And it should be fixed to improve the performance. This might be due to the low priority of the function that fetches more log entries. Currently the priority of the idle source is G_PRIORITY_LOW. I played with the priority a bit and found that changing it to a higher value (for example G_PRIORITY_HIGH_IDLE) does make it a lot faster to scroll down the list. But even with the priority set to a relatively higher value, there is a delay(1 second-ish) for updating those widgets after some log entries are fetched. I'll spend more time on investigate this issue and see what the real problem is.
Created attachment 355058 [details] [review] Remove GtkSizeGroup to improve performance of scolling This performance issue is caused by GtkSizeGroup. Adding too many(hundreds and maybe thousands of) widgets to a GtkSizeGroup does influence the performance quite a lot.
Comment on attachment 355058 [details] [review] Remove GtkSizeGroup to improve performance of scolling Pushed to master as commit 808466cfb6d8358e1d4766b9497634e58aa98718.
(In reply to Jonathan Kang from comment #6) > Comment on attachment 355058 [details] [review] [review] > Remove GtkSizeGroup to improve performance of scolling > > Pushed to master as commit 808466cfb6d8358e1d4766b9497634e58aa98718. Awesome to see this quick reaction and also a solution! Much appreciated :) Just a side question: Will this arrive as a "bugfix" to GNOME 3.22/3.24 or will we have to wait for 3.26 to use it?
(In reply to David Novák from comment #7) > (In reply to Jonathan Kang from comment #6) > > Comment on attachment 355058 [details] [review] [review] [review] > > Remove GtkSizeGroup to improve performance of scolling > > > > Pushed to master as commit 808466cfb6d8358e1d4766b9497634e58aa98718. > > Awesome to see this quick reaction and also a solution! Much appreciated :) > > Just a side question: Will this arrive as a "bugfix" to GNOME 3.22/3.24 or > will we have to wait for 3.26 to use it? Emm. I'm afraid not. We usually don't fix bugs in former branches for the sake of stability.
Really? I thought that that only applied to new features (which is obvious).. Bugfixes doesn't usually change behavior or API, so it should be pretty straightforward to backport them. But I understand why you don't do it with fixes like this one. But do you do it with security bugfixes (I hope so)?
(In reply to Jonathan Kang from comment #5) > Created attachment 355058 [details] [review] [review] > Remove GtkSizeGroup to improve performance of scolling > > This performance issue is caused by GtkSizeGroup. Adding too many(hundreds > and > maybe thousands of) widgets to a GtkSizeGroup does influence the performance > quite a lot. Performance has improved a lot now and it does not lag while scrolling in the events list. Thanks for working on this !
Fix is also pushed to gnome-24 branch, and I made a new 3.24.2 release. As 3.22 is relatively old, we won't backport the patch to gnome-3.22 branch.