Speed enhancement needed badly!

[ye]

I've compared the original GitX and this fork of the GitX and found out on a large Git local repo (1.7G in size, 27k commits), this fork is 5x-6x slower!

Invoking the GUI from command line on the same repo, original GitX tooks about 2 seconds, whereas this fork took around 10-12 seconds. Not sure what else stats do I need to provide, but here are some:

Notice that there is no significant improvement on load time after doing garbage collection.

$ git gc
Counting objects: 375793, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (95330/95330), done.
Writing objects: 100% (375793/375793), done.
Total 375793 (delta 230288), reused 372431 (delta 228128)
Removing duplicate objects: 100% (256/256), done.
Checking connectivity: 375793, done.
$ git log | wc -l
   27457
$ du -sh .
1.7G    .

I understand that there are quite a bit of bells and whistles added comparing to the original GitX, but it shouldn't be that much slower. Is it because of loading git commit objects all at once upon starting?

[rowanj]

I've noticed some degradation myself, I think it's largely due to my repository watcher changes not scaling as well as I'd hoped.

My primary repository is ~8,500 commits and 12,000 files; and loads practically instantly (about the same time as the window-reveal animation) in a clone I made last week; but takes ~9 seconds on a clone that's 6 months old.

For people looking for a quick fix, I've noticed that performance issues with this fork tend to be due to:

• unreclaimed garbage (as you've eliminated in this case); remedy with git gc
• large numbers of uncommitted files (build products in subdirectories) - somewhat mitigated by ignoring them
• concurrent Git-aware tools open on the same repo (esp. Xcode, somewhat Eclipse) - this needs better handling of refreshing (locking and back-off) within GitX
• (less commonly) having many remotes configured

[ye]

@rowanj thanks for your response and sorry about the long due reply. While the size of the repo may or may not be a factor to cause the sluggish performance on the GitX, it could also be due to the fact that it has almost 3k tags and 160 branches.

$ git br -r | wc -l
     164
$ git tag | wc -l
    2918

[rowanj]

That'd definitely be a consideration - I'll replicate that in my performance test repo (a clone of the mainline Linux kernel)

[rowanj]

Needs testing in 0.14.83+ - should be fixed by #158 / #157

[rowanj]

@ye Is the current version working better?

Could you also please test https://github.com/rowanj/gitx/releases/tag/builds/testing/1 - it has entirely new history loading code, and I want to catch any performance regressions before I publish the next build.

[ye]

Hi Rowan,

I will try to retest. I left my last job months ago so I don't have the same git repo to test now but I will still try to pick a few others.

Sent from my iPhone

On Aug 19, 2013, at 12:16 AM, Rowan James notifications@github.com wrote:

@ye Is the current version working better?

Could you also please test https://github.com/rowanj/gitx/releases/tag/builds/testing/1 - it has entirely new history loading code, and I want to catch any performance regressions before I publish the next build.

—
Reply to this email directly or view it on GitHub.