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.
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".
Hi folks, While the full post is over on our blog I'd like to share the dark theme we've got planned for 2019 here directly as well to keep the discussion going. The ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events