After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768651 - gitg is generally slow as of 3.20
gitg is generally slow as of 3.20
Status: RESOLVED FIXED
Product: gitg
Classification: Applications
Component: gitg
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: gitg-maint
gitg-maint
Depends on:
Blocks:
 
 
Reported: 2016-07-11 08:29 UTC by Timur Kristóf
Modified: 2016-08-14 08:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Timur Kristóf 2016-07-11 08:29:18 UTC
I've got gitg-3.20.1-1.fc24.x86_64 (latest Fedora 24), and it is noticably slower than any previous version while performing general tasks.

The symptom:
The GUI of gitg stops responding and 'top' shows gitg taking 100% CPU. Depending on the situation, this can go on for a couple of seconds, up to several minutes until the GUI becomes responsive again.

Steps to reproduce:
1. Clone this repo: https://github.com/Venemo/puzzle-master
2. Add it to gitg
3. Click on the repo in gitg's start screen
4. Click on various commits on this right-side pane (just click on any 10 commits in no particular order)
5. Click on the back button on the top left
6. Witness as gitg consumes 100% CPU for a couple of seconds before it actually goes back.

The above repo is not that big, so it's not so bad, but the issue gets worse as you work with bigger/older repos, to the point where it becomes completely unusable.

This issue was not present in gitg 3.18 (which let me work with large repos without a hitch).
Comment 1 jessevdk@gmail.com 2016-08-14 08:29:00 UTC
Should be fixed on master. The issue was caused by clearing the commit model which caused selection of the tree to be changed for every commit above the currently selected commit (which in turn would start to run a diff etc.). This meant that the older the commit you had selected, the worse performance got when clearing the model (e.g. going back to the dash).