SourceTree slow in Windows 7 x64...
Asked by cprcrack:

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?


Answers:
author: Marko ?logar
body: 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

<http://downloads.atlassian.com/software/sourcetree/windows/SourceTreeSetup_1.5.2.exe>

comments: author: rastographics
body: huge performance boost by downgrading to this version. thanks!


author: peter_pilgrim
body: 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


author: peter_pilgrim
body: 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


author: LEGACY KRIS
body: So much faster, thank you!


author: Alexandra Stanca
body: Thank you !!!


author: joelmez4
body: work like charm!


author: Paul Hester
body: Try the following:

    git config --global core.preloadindex true

    git config --global core.fscache true

    git config --global gc.auto 256

comments: author: svandragt
body: 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.
* **gc.auto** makes git do less garbage collecting.


author: Alex Beardsley
body: Amazing! This did the trick beautifully running version 1.9.6.1 (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.


author: Greasy Touch
body: 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.

comments: author: Bal?zs Szakm?ry
body: Kudos for waiting hours. :)


author: Bal?zs Szakm?ry
body: 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.


author: Seth
body: 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).


author: douglascayers
body: 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](https://community.atlassian.com/t5/SourceTree-discussions/SourceTree-2-0-is-horribly-slow-and-not-scaling-well-on-Windows/m-p/597264#M182), worth a shot to make sure not only is SourceTree current but the embedded Git is current too.

***Tools \> Options \> Git*** ![2017-08-30_9-34-34.png](https://community.atlassian.com/t5/image/serverpage/image-id/5434iB97F115DE7F67744/image-size/large?v=v2&px=999 "2017-08-30_9-34-34.png")

comments: author: svandragt
body: 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.


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


author: Aragorn Yang
body: 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](http://www.systemroot.ca/2014/08/fix-sourcetree-slow-on-windows/). I let my firewall trust SourceTree and I got a huge performance boost.

comments: author: Jani Alatypp?
body: 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 1.6.17.0.hail PrivateFirewall 7.0


author: Rick Strahl
body: 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 ---


author: Alex Reed
body: 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.


author: Seth
body: 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](https://answers.atlassian.com/questions/252979/comments/10412827), are not universal, so the devs may be struggling just to reproduce the issues.


author: Andr? Felix
body: Hi!

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](http://www-03.ibm.com/software/products/pt/trusteer-rapport) the problem gone.


author: C Monster
body: 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....


author: Raul Sobon
body: 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.

comments: author: Raul Sobon
body: 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.


author: Patrick Nelson
body: 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.

comments: author: Mike Friedrich
body: 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.


author: Martin_Lichtblau
body: Yes, it's super slow on all kinds of sytems.


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


Tags: performance

windows