You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
My computer is a beast: 16GB RAM, 1TB of SSD... In general, all the apps perform excellently. But SourceTree is so slow...
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?
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
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
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.
For those interested in tracking the progress of this bug, you might want to "Watch" https://jira.atlassian.com/browse/SRCTREEWIN-2093. 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 v184.108.40.206 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 > Git
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.
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 220.127.116.11. 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 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.
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....
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.
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.