SourceTree is very slow on windows 7

[Luke De Feo]

I love the look and ui of source but its so god damned slow on windows. I have only a few tabs open and simple operations like adding/staging files, commit etc all result in the spinner coming up killing the ux. Also network tasks like pushing and pulling seem to take way longer than on the command line or with smart git.

i have a quad core i5 8gb ram and an ssd so im hardly running light and am on the latest version of source tree 1.3.3.0

any ideas?

Thanks

[Seth]

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).

[jojo665]

i tried both 1.52 and 1.63, although faster, but they are both very slow still (esp compare to OSX version).

however, i just tried github windows client, their performance is matching much closer to sourcetree OSX....

thanks

[mdolnik]

Same issue where source tree would slow to a crawl... usually when previewing previous large commits... downgrading to http://downloads.atlassian.com/software/sourcetree/windows/SourceTreeSetup_1.5.2.exe fixed the issue

[mdolnik]

Just to update, most of the slow-ness has been resolved for me with newer versions of source-tree. I am currently using 1.6.14.0 with none of the issues I had before.

[Samir Sabri]

I had 1.6.14, and it was very slow on Windows 7, actually, it was not responding,

I have uninstalled 1.6.14 and installed 1.5.2, and I can work again ..

[Brian Dayhoff]

I run sourcetree on both a macbook pro running Mavericks, and a windows 8.1 machine at work. The windows installation is painfully slow for all operations. I am tracking most of the same repos on both machines, and the mac consistently outperforms the windows box.

About a month ago, the windows version became so slow it was basically unuseable. This actually turned out not to be windows, but a conflict with Comodo firewall which slowed all git operations to a crawl. I added exceptions to Comodo (can't uninstall it because it is an enterprise setup and the IT department would freak), which improved the speed significantly, but it still falls way short of my home laptop.

Don't quote me on this, but I suspect it has something to do with the way that DOS is configured with windows. A Unix shell works below the operating system level, which DOS also used to, however several versions of windows back they decided to emulate it within the windows environment instead, which has caused a great deal of lag with numerous command line operations ever since. With the additional overhead of all of the windows processes, it would stand to reason that the baseline git commands would not perform nearly as optimally as they would on a command line interface lower on the stack.

Sourcetree is not the only application that has this issue. Netbeans has a similar problem, not because there is anything wrong with netbeans itself, but more because windows handles the JDK painfully slowly compared to a Mac or Linux setup, which in turn affects all applications built on top of it.

[M. Straver]

Check. Sorry for the noise. I'll repeat myself over there, then.

[Seth]

There is also a status update from a developer from mid-May in the comments of that bug, which is far more recent than anything here.

[Seth]

This bug (https://jira.atlassian.com/browse/SRCTREEWIN-2093) has been given attention. It hasn't been resolved (as you are observing on your own machine), but there are notes in the comments about particular features that seem to degrade performance.

[M. Straver]

Well, I assumed since Atlassian pointed me here with feedback, and this applies to me, that Atlassian people would actually be paying attention to these threads. Since above atlassian staff indeed responded, i thought I'd add my experience to it and that yes, it's still a problem. If "you guys in this thread" have any better place for me to actually bring this matter up, as opposed to the Atlassian guys I was addressing as a general direction, then I'd like to hear it, but this seems to be the only way of communication around (apart from adding a bug to JIRA which was done before for different issues at the time of the 1.6 transition, and not given any attention either)

[Seth]

The only "you guys" in this thread are other users, who have no control over SourceTree's performance. You should read through various workarounds in the linked bug report. If the issue is still bothering you, vote that bug up, and if you've got helpful information, add it in the comments on that bug report.

[M. Straver]

Tried 1.6.14 today after giving you guys plenty of time to sort out the painful issues I ran into in my previous upgrade to 1.6 which forced me to go back to 1.5.2 (which works a charm apart from one known crash issue). I'm having severe slowness as well on Win 7 x64, dedicated (high end) graphics card, plenty of RAM. repositories without submodules, usually, and it's definitely directly related to the UI, and not to any hg/git updates or refreshes. Even the application menu is visibly drawn. The slowness (apart from other issues with the new UI that still have not been solved) is absolutely restrictive. I would greatly appreciate it if you would consider making a bugfix update to 1.5.x for known crashes, so those of us suffering from this can continue to use the client effectively.

[Valentijn de Bouter]

Same issue, SourceTree is incredibly slow on windows 8.1. i7 processor, 16GB memory and SSD, so pc config should not be a problem. It seems to be a particular problem when staging new files and staging multiple changes in multiple files. A few changes in 2 or 3 files seems fine.

I'm running 1.6.3.0 currently, but am switching  back to 1.5.2 since it has been reported to be a lot faster.

[Lynn Roth]

Confirmed as well.  1.5 actually works. 

We are in the middle of switching to the Atlassian tools (Stash, Jira, Confluence) and 1.6 was causing so many issues that I was very discouraged.

Does Atlassian have any plans to actually fix SourceTree?

[Vinko Vrsalovic]

I can confirm. Repos with huge amount (> 1000) of TRACKED files are awfully slow on 1.6. On 1.5 it's back to usable.

Also, on an unrelated note, the terminal upgrade on 1.6 sucks

[John Bolton]

I have to agree that SourceTree is painfully slow for me also. Even a simple refresh can take 30 seconds or more. I love the interface but I only use it for the commit log display and a few complicated operations. I am forced to use the git command line most of the time for most work. I'm using 1.6.11.0

[bitsnow]

I was also forced to downgrade to version 1.5.2. It is orders of magnitude faster than 1.6.x.

[Pleun Vanderbauwhede]

I've been struggling for months now with a SourceTree that was nearly impossible to use due to slowness, hangs & crashes. Just switching repository and loading in the commit log is usually already enough to cause a full minute hang. I always assumed there was something funky going on somewhere not necessarily SourceTree related and hadn't had time to do a format so tried to ignore the issue. I did a reinstall last week on a new system, configured 5 (not even that large) repositories and had the exact same problem again, on a brand new install. Landed on this page and figured I'd give the 1.5.2 downgrade a shot.

Well, it works. Not sure what is going on in 1.6.x but it absolutely kills performance for me to the point it's pretty much unusable. 1.5.2 however works like a charm.

I've tried everything I could think of: set up repositories from scratch, ignore the code directories from any kind of indexing or malware scanning, explicitly allow everything sourcetree & git related through the firewall, checked process monitor logs, nothing seems to help.

[James Selleck]

I was running TortoiseHg and Kiln Tools also - I removed these, and switched SourceTree to use Embedded Mercurial and Embedded Git (we have both types).. and speed was greatly improved.

[Deleted user]

Just wanted to share my experience. I have a git repo that was migrated from TFS, and it included all the nuget package files (about 1000). Any commits which had a large amount of files (around 1000) hangs the Sourcetree UI. I downgraded to 1.5.2 and the UI hanging problem went away

[Jerimiah Baldwin]

Down grading also worked for me! Thanks for the suggestion! This is very frustrating because I recall "upgrading" to get past other bugs. Now I have to live with those bugs for the sake of acceptable performance.

[LanceS]

Down grading to 1.5.2 also helped for me thanks @Robert Sirre and @Alberto Fernández

[albertofb1]

Thank you very much @Robert Sirre. I have uninstalled 1.6.11 version and installed 1.5.2 and now everything is going much faster. 1.6 version took me until 3gb of memory ram and ten minutes to load the list of files. 1.5 version do instantly all this actions

[LanceS]

Such a great interface but way to slow to be useful (both windows 7 & 8) We still have to use Tortoise for now but look forward to when SourceTree is useable

[Leon Cullens]

Can confirm. 1.5.2 is significantly faster than all 1.6.xx versions. I'd love to get access to the source code and profile the performance issues.

[Robert Sirre]

1.6.11.0 seems to be even slower, my colleague also downloaded 1.5.2. This version is still available at: http://downloads.atlassian.com/software/sourcetree/windows/SourceTreeSetup_1.5.2.exe