author | Paul Mackerras <paulus@samba.org> | |
Wed, 10 Aug 2005 12:50:28 +0000 (22:50 +1000) | ||
committer | Paul Mackerras <paulus@samba.org> | |
Wed, 10 Aug 2005 12:50:28 +0000 (22:50 +1000) | ||
commit | 466e4fdd6696c89700294e1a54fa73e1fb94643b | |
tree | 913e53f0b6d45ddc8050a4dce9c685b62a882f74 | tree | snapshot |
parent | b1ba39e7e80cdee3e7c1c80334cd9aa87b9b7b69 | commit | diff |
Only do an update every 100 commits when drawing the graph.
On a large repository with > 60,000 commits, each call to the Tk
update primitive (which gives Tk a chance to respond to events and
redraw the screen) was taking up to 0.2 seconds. Because the logic
was to call update after drawing a commit if 0.1 seconds had passed
since the last update call, we were calling it for every commit,
which was slowing us down enormously. Now we also require that we
have drawn 100 commits since the last update (as well as it being
at least 0.1 seconds since the last update). Drawing 100 commits
takes around 0.1 - 0.2 seconds (even in this large repo) on my G5.
On a large repository with > 60,000 commits, each call to the Tk
update primitive (which gives Tk a chance to respond to events and
redraw the screen) was taking up to 0.2 seconds. Because the logic
was to call update after drawing a commit if 0.1 seconds had passed
since the last update call, we were calling it for every commit,
which was slowing us down enormously. Now we also require that we
have drawn 100 commits since the last update (as well as it being
at least 0.1 seconds since the last update). Drawing 100 commits
takes around 0.1 - 0.2 seconds (even in this large repo) on my G5.
gitk | diff | blob | history |