SourceTree slow
Asked by Filip Verhaeghe:

Hi,

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.

Filip.


Answers:
author: lambdamix
body: An example of repo for which SourceTree is very-very slow (and often uses 100% of cpu) is [](https://github.com/JetBrains/intellij-community.)<https://github.com/JetBrains/intellij-community>. (I use SourceTree 1.9.7 for Mac)

comments: author: Seth
body: Excellent! There is a [bug report open](https://jira.atlassian.com/browse/SRCTREE-1885). If you post this there, that should help Atlassian staff significantly. Currently they're just going off of details about usage (number of repositories, versions, etc).


author: bs-thomas
body: 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".

SourceTree v2.4.8.0


author: Filip Verhaeghe
body: 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.


author: Seth
body: 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](http://support.atlassian.com)(support requests) or [jira.atlassian.com](http://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.