We have a bunch of repositories. Most of these are relatively small in content and/or history, and SourceTree flies on these repositories. We have one 2 year old repo, with 10-s of gigabytes of repo, 10-s of thousands of tags, no untracked files, no large changes. This is a repo with a wild youth growth that now only sees minor maintenance updates. We have already tried to have Git optimize the performance of the repository.
On that repo, SourceTree cannot be used because it is just too slow. I have read some Atlassian Answers, where Atlassian saying the problem is with Git, but for us this is not (directly) the case. Doing the operations on this particular repo from the command line is not fast (`git status` takes 5 seconds), but usable. That same repo in SourceTree easily takes 5 minutes to come up with the first screen.
I suspect the problem is that SourceTree is requesting many different data items from Git, and those second responses add up to minutes. Given that the main information of Git (e.g. `git status`) is available in seconds, it seems there must be ways to dramatically improve the speed of SourceTree using multiple threading in the UI, providing partial information as it is available. I'm sure you already do that, and I am sure it's not that simple, we're all software engineers here. And it could be something completely different, such as the way the tags are processed. But it seems worthy of a brainstorming meeting with your team.
Interestingly, the performance of the same large repo is significantly different from one laptop to the next, whereas the Git command line performance is not so different for these laptops. Not surprisingly, newer laptops are faster. The CPU speeds are probably not the main differentiator between these laptops. Although all laptops are MacBook Pros with SSD, I'm guessing disk performance may be the biggest difference between older and newer machines, and small differences may add up. On some computers, SourceTree can update the screen in just one minute for this repo (which is still nowhere close to 5 seconds, off course).
Let me close by saying we love SourceTree and use it all the time. Just not on this particular repository.
Great question Filip. It is very thorough and polite.
I haven't seen anything like the performance problem you describe on a 7 year old repository (probably more commits) but is only 2 gigs and hundreds (not 10-s of thousands) of tags.
Obviously you need attention from Atlassian on this one. If they don't respond to this question, you might try following up with support.atlassian.com(support requests) or jira.atlassian.com(bug reports). If you post to Jira, please include a link to the issue here in an answer so others can find it and vote for it.
I assume your project is commercial, so you wouldn't be able to give out direct access to it for testing purposes.
Thanks for the suggestions.
Indeed, it is commercial/confidential. And due to process auditing trail needs, we also cannot throw away the past history, and start over with a clean and lean repository, which would have been the easiest solution.
I'm also seeing a lot of CPU and memory used by SourceTree. It's loading very slowly for every little action I make (viewing a branch, opening options, clicking OK etc.)
It's basically unusable, and my SourceTree taskbar always says "Not Responding".
Supported Platforms macOS Windows To make using Sourcetree as simple yet powerful as possible we embed (bundle) dependencies such as Git, Git LFS, and Mercurial. We strive to keep these...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG