guberm / tortoisegit

Automatically exported from code.google.com/p/tortoisegit
0 stars 0 forks source link

TortoiseGit UI blocks when operating big git repository(like qtwebkit-2.3): git log with "All Branches" checked #1907

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
WTortoiseHg UI blocks when operating big git repository(like qtwebkit-2.3): git 
log with "All Branches" checked

i use the qtwebkit-2.3: https://github.com/qtproject/qtwebkit

When i use the newest 1.8.5.0 x64 on my i5+8G laptop, the UI always sucks into 
blocking state.

There MUST be a bad algorithm-related performance problem.

Original issue reported on code.google.com by ctengc...@gmail.com on 17 Sep 2013 at 6:19

GoogleCodeExporter commented 9 years ago
Please report to TortoiseHg team.

Original comment by sstrickr...@googlemail.com on 17 Sep 2013 at 11:20

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Sorry, i made a typo mistake, but i mean TortoiseGit

Original comment by ctengc...@gmail.com on 19 Sep 2013 at 8:59

GoogleCodeExporter commented 9 years ago
I cannot reproduce this issue. However, I just noticed some similar issue with 
another 2GB repository, but only once.

Original comment by sstrickr...@googlemail.com on 19 Sep 2013 at 9:11

GoogleCodeExporter commented 9 years ago

Original comment by ch3co...@gmail.com on 21 Sep 2013 at 3:01

GoogleCodeExporter commented 9 years ago
I can also attest to slowness in Tgit show log dialog.
Our repository is very large, 11GB for a newly cloned bare repo, and ~170,000 
commits.
56,000 files in worktree.
Working on core i7, with a SSD HD and 8GB RAM.

Initial Show log operation on the repository folder can take 2-5 minutes 
easily. Subsequent Show Log operations are much quicker (due to cache, no 
doubt). 
But Show Log on a repository folder is often worse, and takes long minutes to 
display.

A quick fix would be to allow limiting the number of commits to read off the 
log. Limiting the history using the date field is not helpful as it often 
forgets the last set value. This is especially annoying when:
1. Use Show Log on the repo folder and Set "Since Date"
2. Use Show Log on an internal folder within the repo, and set the "Since Date"
3. Try Show Log on the repo folder again, and Tgit is reading all the history 
again.

Version 1.8.7 is working a little better, I believe, but far from perfect.

Thank you!

Original comment by sol...@gmail.com on 5 Feb 2014 at 7:18

GoogleCodeExporter commented 9 years ago
the log dialog stalls when displaying an initial commit with 110'000 files, 
contrary to other tools like atlassian, etc. 

allow me to copy the original mail to the users list here 
(https://groups.google.com/forum/#!searchin/tortoisegit-users/rupert/tortoisegit
-users/i_oB6oVlOCs/5VnQB26QRkoJ ):

hi,

tortoisegit was rock-stable and ultra-quick in everything i tried with it up to 
now.

there is one exception though: recently i tried to use the log viewer on a git 
repository with a large initial commit of 100'000 files, then subsequent 
commits of 100 - 1000 files. browsing the commit history with arrow down/up 
lets it stall for quite a long time (1 hour?). as the number of files in a 
commit is not displayed, i tried to count by marking all with ctrl-a. it is 
only slow for the 100'000 files (a couple of minutes).

that tortoisegit is slow came with surprise, as "git diff --name-only sha1 
sha2" is quite fast on the command line, e.g.
$ time git diff --name-only 04d db5 | wc
 100280  103004 9030193
real    0m1.042s

to compare, i tried atlassian sourcetree, which takes a minute or so to open 
the repository, switching between commits is then fast (enough). from time to 
time this also takes 20-40 secs, but normally below 3 sec.

is there any option to speed this up i did not notice so the gui keeps being 
responsive? e.g. interrupt the current operation if a different entry in the 
history is selected, or not display all files.

btw, we set the two options to speed up especially 'git status':
$ git config --global core.preloadindex true
$ git config --global core.fscache true

rupert

Original comment by rupert.t...@gmail.com on 30 Jun 2014 at 11:06