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?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

SourceTree slow in Windows 7 x64...

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?

Accepted answers

All comments

Seth

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.

Balázs Szakmáry

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.

Prashant_Deva

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

Martin_Lichtblau

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

Greasy Touch

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.

Balázs Szakmáry

Kudos for waiting hours.

Alex Reed1

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.

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

Rick Strahl

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

Marko Žlogar1

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

rastographics

huge performance boost by downgrading to this version. thanks!

peter_pilgrim

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

peter_pilgrim

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

Patrick Nelson

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.

Mike Friedrich

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.

Paul Hester

Try the following:

<span class="pln">git config </span><span class="pun">--</span><span class="pln">global core</span><span class="pun">.</span><span class="pln">preloadindex true</span>

<span class="pln">git config </span><span class="pun">--</span><span class="pln">global core</span><span class="pun">.</span><span class="pln">fscache true</span>

<span class="pln">git config </span><span class="pun">--</span><span class="pln">global gc</span><span class="pun">.</span><span class="pln">auto </span><span class="lit">256</span>

Aragorn Yang

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.

unknown

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.

Raul Sobon

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.

Jani Alatyppö

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

C Monster

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

svandragt

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.

Alex Beardsley

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.

André Felix

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 the problem gone.

douglascayers

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 > Git

svandragt

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.

William Lim_d7crnu

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

sourcetree

performance

windows