Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

SourceTree slow in Windows 7 x64...

My computer is a beast: 16GB RAM, 1TB of SSD... In general, all the apps perform excellently. But SourceTree is so slow...

  • About 200-400 ms delay when I click on a commit.
  • About 500-1000 ms delay when I click on a file to see the diff.
  • About 1000-3000 ms delay to update and show the uncommitted changes when I come back to the SourceTree window.

I used TortoseGIT before and the delays were almost 0 for any of the previous actions. I've been waiting for several updates but there are only minor fixes. I'm very disappointed. Seriously guys, you have some performance issue that seems to affect almost every common action...

Please be sincere, are you putting any effort on this?

16 answers

We had the same issues at company I work at. Almost everybody reverted to old version of Source Tree 1.5.2.

Here's the link

huge performance boost by downgrading to this version. thanks!

There could be a memory leak in the application Windows, because I watch in `Process Explorer' the `Private Bytes' column consistently grow from 540,000K to 779,000K for 1 minute before I killed the SourceTree.exe process. I downgraded to 1.5.2 as well. In this old version, The Private Bytes is 116,564K around that the Working Set 137,280K

There could be a memory leak in the application Windows, because I watched the process in `Process Explorer' and in particular observed the `Private Bytes' column consistently grow from 540,000K to 779,000K for 1 minute before I killed the SourceTree.exe process. I downgraded to 1.5.2 as well. In this old version, The Private Bytes is 116,564K around that the Working Set 137,280K

So much faster, thank you!

Try the following:

git config --global core.preloadindex true
git config --global core.fscache true
git config --global 256

Still testing this solution for any side effects, but it really speeds up large repositories with a lot of commits. From my research:

  • core.preloadindex makes things like diff multithreaded.
  • fscache enables the filesystem cache.
  • makes git do less garbage collecting.

Amazing! This did the trick beautifully running version (latest as of now 11/8/2016). I love SourceTree's features and ease of use, but it's crazy that it is still so slow since the original post 2 years ago.

same here... slow to a crawl. if i click on a relatively large changeset, sourcetree would freeze for hours before it's able to show the content.

Kudos for waiting hours. :)

3 votes

I have used SourceTree extensively with all kinds of different repos and it seems that the speed varies with the size of the repo being used and the access speed of the disk.

For a repo with x*10k files, a few GB repo size and looong history, the responsiveness of SourceTree is very bad.

On the other hand, with a test repo of ~100 files, 200kB repo size and a few hundred commits, it is quite OK. (Some operations are quite slow even on this, e.g. it takes ~15 seconds to create a stash containing one change to one text file with 5 lines of text in it.) Even with this small repo, there is a noticeable delay between clicking something and the action.

All this seems to be relatively independent of RAM and CPU (my laptop has 8GB RAM and 2 cores, my desktop has 12GB RAM and 2*6 cores), the only spec that seems to matter for some operations is the speed of the disk (SSD or HD).

After a while, I just stopped using SourceTree for the large repos. If I need the graph, I use Git Extensions, otherwise Tortoise Git or the MS Git provider in Visual Studio for the simple stuff.

BTW the speed (or at least my experience) has not improved at all in the past 1.5 years or, so since I started using SourceTree.

2 votes
Seth Rising Star Jan 05, 2015

For those interested in tracking the progress of this bug, you might want to "Watch" Please don't post comments on the bug unless you have useful information to contribute ("SourceTree consistently slows every time I perform these steps:..."; "My SourceTree log has this message that looks related"). If you simply want to confirm that you're experiencing the issue, click the Vote button on the bug.

You can see by reading through existing comments that Atlassian is trying to improve performance, but they are having trouble duplicating the type of slowness you guys are reporting. (I am not Atlassian staff, but I also don't have any performance problems).

On Windows 10 x64 with SourceTree v2.1.11.0 I the app was slow for me too. Would take 3-5 seconds or more for SourceTree to scan and detect file changes even in small repos with only a hundred text files of 300 lines or less each. Trying to open another bookmarked repo would sometimes freeze the app entirely.

I then noticed that the embedded Git version was out of date so I updated it and after restarting SourceTree now everything is snappy again.

Coincidence or perhaps related to this conversation, worth a shot to make sure not only is SourceTree current but the embedded Git is current too.

Tools > Options > Git2017-08-30_9-34-34.png

Following your instructions, I successfully updated to the latest SourceTree; I then Updated Embedded Git, which failed (lol) with an unpacking error dialog.

Manual fix for that is to unpack %appdata%\..\Local\Atlassian\SourceTree\PortableGit.7z and rename the PortableGit folder to git_local, followed by running post_install.bat inside that.

Edit: I have a different version of Windows, so my comment isn't relevant.

I am on Win7 x64 with 8GB of RAM and a SSD. I started with SourceTree v1.6.14, it's painfully slow with even just one local repo. The performance didn't improve after I downgraded to v1.5.2. Then I found SourceTree: Fix for Slow Operation on Windows. I let my firewall trust SourceTree and I got a huge performance boost. 

Thanks for the link. Changing away from Comodo totally worked for me. I had disabled any antivirus part of it(Avast for that) and whitelisted SourceTree's local git, but still 2-10sec delay on everything. I was seeing like up to 10 git.exe + 10 sh.exe processes munching away all 4 cores. Works totally smooth now on Win7 x64 with SourceTree version hail PrivateFirewall 7.0

I'll throw in my 2 cents here: I have about 50 repositories I routine access from SourceTree, of all different sizes and I see a huge variance in performance and it doesn't seem to be directly related to the repository size. I have two small projects that have about 20 files in them with short commit history, and I see the same 'hanging for 10-15 seconds or more behavior described by others. THen I have a large project with 5000+ files and massive history and it works nearly instantly.

I think it has something to do with disk access/permissions or maybe interference from another git provider (like Visual Studio maybe)? I haven't been able to make sense of it but I can see why Atlassian seems to have problems tracking this down. I also wonder if there's something internal that SourceTree is doing - caching files/history etc. that might get corrupt because it seems that immediately after updates things seem to work better for a while before deteriorating again.

+++ Rick ---

I came to this forum to say the same thing as OP.

Windows 7 install, and ever since the last couple updates SourceTree regularly goes into (Not Responding) mode. That's all good and well, except I can't use the application. Running on my Mac side is seamless, however. 

1 vote
Seth Rising Star Nov 18, 2014

I can only speak for myself, but I don't see the same performance. Clicking on commits changes the UI instantaneously, and loading the diff view seems to take more like 100-200ms (.1-.2 seconds), which is more than reasonable.

I also have 16GB of RAM and a repo on a SSD, but my OS is Windows 8.1.

From reading other posts on this site, seems like the performance issues, while common, are not universal, so the devs may be struggling just to reproduce the issues.


My git was extremelly slow. Just type git in command prompt take more than 60 secs. It seems that SourceTree was slow as a side effect of git slow.
After uninstall IBM Security Trusteer Rapport the problem gone.

I'm running 1.6.x on a 64bit Windows 7 machine with 3.4ghz, 4 core Athlon CPU with16GB of ram and it's slow as molasses in the wintertime. I watch it chew up slowly chew up 3.5GB while Windows tells me that it's hung. I also have a Windows 10, 4GB Intel Core Duo laptop running the same version of Sourcetree seemingly without problems, it tops out at using just over 200mb of ram. Interesting....

0 votes
Deleted user Mar 20, 2015

I've found that sourcetree may not compress (run git gc / git prune) on a regular basis or if it does, it may be failing silently. Running git gc and git prune made things run quickly again. I think it was failing silently in my case because I needed to disable Symantec before it was successful.

Damn Symantec, scanning source code files or log files, yeah that will work... I remember one place had it delay all file IO by 200ms per .c .h files (local and smb), making checkouts slow, and compiles slow for at least 10 years.

It's a shame that the application is coded in such a way that you get such significant performance boosts by downgrading only a minor version. Interestingly enough, I had this issue before in v1.5 and the fix back then for me was to run it as administrator.

I too am on Win7 x64 with 16GB of RAM, everything is on a SSD.

I agree, its bad design if the UI runs potential long running actions synchronosly and without a mechanism to cancel them. I understand that some git actions may take longer, but thats no reason for the UI to become unresponsive.

Yes, it's super slow on all kinds of sytems. 

since the latest update sourcetree has slowed to a crawl. it was fine before. please fix this. 

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events