SourceTree painfully slow

fcorreia February 8, 2013

SourceTree is running very, very, slow at times. Restarting it seems to work temporarily, but it's still quite a nuisance, specially when I have to do it every couple of ours. When ST starts slowing down, I also see the CPU usage rising to 80%-300%.

I'm using SourceTree 1.5.7.1 now, but it was also happening with 1.5.7.

This might be the same issue. See my process sample taken with Activity Monitor here.

34 answers

1 accepted

3 votes
Answer accepted
KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 14, 2013

Your clue was in your second-to-last sentence (around 13,000 untracked files). This is a Git problem rather than a SourceTree one. There are two solutions to this problem

  1. Ignore the files you don't want (perhaps all 13,000 of them)
  2. Use the 'Show Modified' filter - this is the same as 'Show Pending' except it omits untracked files.

It's a Git performance problem from the looks of it.

Have a try and let us know how you get on. Cheers!

fcorreia February 20, 2013

Thanks, that is it! It's still annoying keep changing the filter... but it's a workaround that works. I guess the solution will ultimately be to change my directory tree, and move all those unversioned files to somewhere else.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 21, 2013

Or more simply, just right-click > Ignore...

Like # people like this
Léon Pelletier September 12, 2014

Showing modified files doesn't allow deleting rejected files.

Shankargouda Annigeri December 15, 2020

Still facing the issue it’s too slow

Lee Haw Ong January 6, 2021

I have the same slowness and it is not due to having huge number of untracked files. I ran "git status" on my local repo and the first time it took a while to refresh index. The second time it finished immediately. Afterwards my Sourcetree is snappy again. From some Googling you can also do "git update-index".

You might want to give this a try. Hope this helps you.

18 votes
Deleted user February 16, 2014

Simple solution for me (Win7 x64): Run it as administrator!

Patrick Nelson December 31, 2014

+1 here. Oddly enough, this works for me (was an easy fix). I've been having this issue for quite some time for thanks for the comment!

Like # people like this
Gonzalo Martinez May 4, 2016

This did the trick for me as well, wtf ? Anyway, thanks Oliver.

Aleksandr Kuznetcov December 14, 2016

Wow! Makes a BIG difference!

David Parham May 30, 2017

how do i do what you recommend? "Use the 'Show Modified' filter - this is the same as 'Show Pending' except it omits untracked files." mine is so slow i cannot even get to options and file menu items without it taking an hour. when you explain something, can you take a second to state the click path?

Marcio Barcellos da Silva March 29, 2019

Worked for me. Thank you!

Andrey January 29, 2020

This one is probably the best answer. It makes even an improvement for UI. Thank you very much.

John Michael Go-Soco February 20, 2020

I've just tried this (run as Administrator) and Sourcetree suddenly seems snappier. WTF? 

I'm going to have to do some experiments and try it for a while to make sure this isn't just some sort of psychological thing.

Hooman_Famili March 3, 2020

Running 3.3.8 and this did it for me.  Was very slow working (even switching tabs between open repos). Not it's fast/normal.  

Ps: I had this issue for thee last year with versions 2 and above so not a 3.3.8 thing alone.  The date of OPs message seems to line up with my experience. 

Kirk Chen June 16, 2020

use 2.6.9 fast

use 3.3.8 slow

other version unknow

3 votes
Frode Nilsen January 22, 2014

Ok sorry. Is it OK that we continue this thread even if I'm talking about the Windows version?

I've created a reproducable (at least on my computer) recipe. Please enter these commands from a windows command linewith git support:

git clone https://android.googlesource.com/platform/frameworks/volley
cd volley
echo Hi > src\com\android\volley\Request.java
echo Hi > build.xml

Then start sourcetree, goto master branch and the "uncommited changes" point. The two files build.xml and Request.java should be listed under "Working copy changes". Select build.xml. Press the up-arrow.

At this point my computer uses from ~500 to 1000ms to process the diff. In this timespan, pressing the down-arrow will not trigger any reaction from sourcetree, but will trigger after the diff is presented. If I repeat the process by alternating between up-and down-arrow int he window, the delay is even more obvious.

I have noticed a correlation between the size of the source file and the length of processing (Request.java is some ~18kb). Yet there are two things make me say that this shouldn't take that long:

  1. "git diff Request.java" on the command line peforms way better than Sourcetree
  2. My change is trivial (basically truncated the file)

My computer specs are:

Intel Core i5-2467M @ 1.60 GHz . 6GB RAM. Windows 8. (Toshiba laptop Z830).

2 votes
tapaniz February 26, 2016

Seems like no improvement in performance has happened in the past 3 years. SourceTree is still so slow it's almost unusable. Don't know what it is doing in the background all the time. Going thru all files or what? And why is it doing all this in the main thread blocking the UI?

Using version 2.1 in OS X with Core i7 3.1GHz, 16GB of RAM and SSD...

2 votes
Jasmin Ibrisimbegovic July 25, 2014

How do I disable preview pane completely !?!?

This is ridicilous, my whole PC stuck because of this.

1 vote
Corey Caldwell September 22, 2014

For whatever its worth, when connected to BitBucket, switching to an ssh connection instead of an http connection really sped up all git operations for me both in SourceTree and the CLI.

1 vote
Edmond Mandell November 18, 2013

I'm beginning to think that Source Tree is just very slow full stop, I have one repository maybe a couple of thousand files yet source tree just goes awol every time I do anything.

Git works like a dream on the same repository under Linux

Maybe its just me but the same things which take 10 seconds on Linux (command line) seem to take about 1-2 minutes on Windows with Source Tree

1 vote
YGalustov July 15, 2013

Have tried version 1.0.6. for windows

It's much faster then previous versions!

Thx guys.

1 vote
Steven Klass April 21, 2013

I would also jump into this and say that I don't have lots of untracked files. In fact my sisytem is pretty basic and it's slow. It will litterally cause my mustic to pause while it's figuring itself out..

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 22, 2013

By default SourceTree displays files with a filter it calls 'Show Pending', which includes both modified files and untracked files. Unfortunately git itself really starts to slow down when you have a lot of untracked files - usually you don't want to keep lots of untracked files around and you want to ignore them or add them (otherwise it gets hard to see the wood for the trees). However, if for some reason you want to keep all these untracked files sitting in your repo, you can speed up SourceTree by selecting the 'Show Modified' filter instead for the majority of the time. This is a lot faster because it avoids the slow call to list untracked files.

Melville Stanley October 28, 2013

I am using 1.7.3 on MacOS and I have the same issue. When returning to SourceTree from another program I will often have to wait a minute or more while SourceTree grinds away at something. It uses all available CPU and basically makes my whole machine unusable while this is happening. I do not have lots of untracked/unignored files. I have 20 or so git repos, but only one or two windows open at any given time. I can fix this temporarily by restarting, but even getting SourceTree to quit in those times is a painfully slow process.

0 votes
Muhammad Shahmeer Qayyum September 16, 2023

I have faced the same issue when I use SourceTree. After launch, everything seems fine, however after ten minutes SourceTree stalls everywhere, even while changing tabs. I have resolved this issue by shifting to a previous version of SourceTree.

0 votes
Reymond T. Turbanada February 2, 2020

For a Filipino like me,

I encounter that problem.

Here is how I fix that problem.

 

1. Make sure that you already commit your changes and push it in the server you are connected to. 

2. I know that after 5 to 15 seconds you'll be experiencing a lag or "Not Responding".

3. Now, it's time for you to go to the Control Panel and uninstall the sourcetree app.

4. After you uninstall, go to your root directory for example in C://Users/App/ (please locate the location where your sourcetree is being placed)

5. Delete the folder sourcetree and folder Atlassian. ( why I deleted it? because I have so many past commits that I forget to push and many history that my account need to commit and push).

6. I highly not recommend it for everyone who is not willing to take risks. (The risks are you may delete your folder project too, and I know that you have create many changes. I advised that you create a duplicate copy of your project. after cloning it then retrace all of your changes made from the cloned files. Then recreate your commit messages.)

7. I'll do it, I reinstall the sourcetree from my bitbucket account, select the bitbucket server and enter my credentials.

8. and from my server, I'll repeat the process of cloning of my project.

9. And now my Sourcetree is now smooth and very fast to use.

10. I am not highly recommended it to everyone. You have to think of it very carefully why your sourcetree is hanging or lagging all around. 

 

I'm a newbie here and I am just sharing what I did.

 

Thanks, 

Mon

0 votes
Akin Tekercibasi July 5, 2018

For me it made a huge difference to change view from "Tree view" to "Flat list" on Mac with version 2.7.4 (174)

0 votes
bighatsmallfeet January 4, 2018

It's been a while, but I can still recommend the solution earlier in this thread: If on Windows, run SourceTree as administrator. Made a huge difference on my (brand new) machine

0 votes
David McClurg January 9, 2015

May I suggest the problem is the default size limit for Binary Diffs which can be changed in Preferences->Diff

The default is 10MB but I set this to zero (0) and that seemed to fix the problem.  It occurs mainly when you multi-select a bunch of files and the diff panel cannot refresh so the app appears to hang.

0 votes
Patrick Nelson December 31, 2014

+1 to Oliver:  Oddly enough, running as administrator apparently worked for me as well! Huge thanks for this, I've been having this issue for quite some time now.

0 votes
ronpeled May 27, 2014

Hey Guys,

I love Sourcetree, simply the best. I got one big issue with it lately: the last update was not a good one. The whole interface is bad in my experience and it just works so SLOW compared to the version previous to this one. Are you working on this? is this a known issue?

0 votes
Takeshi Nozawa March 27, 2014

Hi, I am Takeshi.

This is my first post here. I want to introduce my case.

My colleagues use sourcetree on win 7 and win 8 and these are too slow.

I tried to solve it with information you provided here.

But I found another aspect ot this problem.

My colleagues are using trendmicro's "buisiness security" which is japanese trendmicro's solution and I don't know the name in another country.

When I stop the trendmicro's process from task manager, sourcetree become much faster.CPU utlization got small too.

And then I change the configuration of trendmicro's unti-virus software to exclude the working tree from monitoring, the result is same as stopping process.

Ofcource, here is risk that we cannot find virus from files while git pull from other remote repository, take care.

0 votes
Frode Nilsen January 22, 2014

Hi guys, came here from googling "Sourcetree cpu usage". Mine is very slow now when switching between uncommited & unstaged files. Suggestion: Dont do the file-compare on the UI thread. It seems as if it is happening now (haven't looked at the code). One should be able to quickly select mulitple files in the "Working Copy changes" pane without having to wait for the result of the Diff-view..

That said... Why are you guys talking about v1.5+? Isn't the latest verson as of Jan 23 2014 v1.3.3?

KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 22, 2014

Hey Frode,

This thread is about the Mac version, hence the version numbers.

We definitely don't do the file compare on the UI thread, we're very careful when it comes to this and lots of testing is involved. It's a relatively obvious thing to perform actions like this on background threads.

We'd need more details to diagnose your issue. If the diff's are big, or lots of files are selected this is usually a result of Git taking a long time to respond.

Cheers

0 votes
Kris Khaira July 18, 2013

Hi Kieran

Thanks for your reply. I had no idea you were not publishing to the MAS anymore. Looks like I missed the recent blog articles about the sandbox issues.

I'm now trying out version 1.6.2.2 and have also reverted the preferences changes I did to know if it makes a difference (still using a fixed-width font for commit messages though).

You might be right about SourceTree being slow when there are a lot of untracked files that are not ignored. However I face this issue regularly not because I'm not ignoring files which should be ignored (in fact I'm quite zealous of keeping my working files list clean), but because I sometimes add folders containing many files which I need to commit later - for example vendor JS libraries. Renaming a folder that contains a lot of files that's already committed will also create a long list of working files. So this might actually be a regular use case that isn't actually due to a neglected gitignore file.

That said, I'll keep using the latest version and report back if there's anything noteworthy. Thanks for making such a great Git client and on top of that, releasing it for free.

0 votes
Kris Khaira July 11, 2013

SourceTree 1.5.6 was slow for me too on a but I managed to get SourceTree to perform a lot faster by doing the following:

  • Set language in Preferences
  • Disable automatic refresh
  • Use fixed-width font for commit messages
  • Set diff context to 1 line

I'm too lazy to figure out which specific one made it faster or whether it was a combination of these settings, but perhaps Atlassian could look into this. Hope it helps. SourceTree was much slower than the latest version of GitX (rowanj's fork) until I made these changes. I also disabled backups on destructive operations but noticed it made no difference when I re-enabled it.

My specs: MacBook Pro 15" late-2011 2.2GHz i7 with 8GB RAM.

p.s. the moderators might want to merge this thread with this other one.

KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 14, 2013

Hey Kris,

1.5.6 is the MAS version. We're no longer allowed to publish to the MAS anymore, the latest version is 1.6.2.2 available on our website.

Regardless of that, your input is very useful, thanks for the insights. I am planning on performance maintenance in the near future. Our Windows client recently got a major speed boost due to investing in performance maintenance a bit more.

Most of the background checking / threading tasks took months to get right. Some people have very large repositories or very slow remotes. One major factor contributing to poor performance are repositories with lots of untracked files in them which aren't added to an ignore list, or where SourceTree's log preferences aren't set to view only tracked files. SourceTree has to call Git, and Git has to do a load of checks on the untracked files causing response to be very poor (because we're asking Git for the information).

I've created an issue here outlining what steps we should take. The first two would make more sense, and the last is imperative also. https://jira.atlassian.com/browse/SRCTREE-1706

Cheers

0 votes
YGalustov July 3, 2013

I use SourceTree and have the same problem. After launch it seems good, but after 3-4 hours SourceTree freezes everywhere even between switching tabs.

I will try to record a video which will demonstrate the issue.

I use windows version 1.0.4.0 and my filter was setted up to 'Show pending'. I don't have many untracked files and have only 7 reps.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 3, 2013

This is actually a different issue (Windows specific) - with all the features that have been added to get us to 1.0 on Windows we haven't had chance to spend time simply profiling to catch things like this - we're addressing that now. I've already managed to speed a great number of things up for the next Windows update (1.0.5), and I intend to try to find some more before that release next week. We'll be improving things all the time; it's still fairly early days for the Windows release.

YGalustov July 3, 2013

Ok, thx Steve.

Will wait the new release.

0 votes
fcorreia February 14, 2013

I usually have only two windows open. The bookmarks window and the window for the project that I'm working on. I can't establish a clear relation between the view I'm at and the slowness. But there are two situations in which I see this issue happening more often: a) when I have the "Uncommited changes" selected in the top panel, and start selecting some modified files (one at a time) to see what my latest changes were, and b) when I open up the commit dialog.

Then again, these are the features that I use more often, so not having felt all the slowness when working with other features of ST may not really mean anything. I spend ~80% of the time is the log view.

Do you have 'All Files' selected?

You mean, if I select all the files in the "Files in the working tree" pane? If so, no.

Are you using large selections with lots of large diffs

No, not really

or selecting ignored/clean/untracked files?

Not really either. But I do have a lot of untracked files in the project that I have been working on recently (around 13000).

PS: Sorry for the delay in answering back, I had to focus my attention on something else in the last 2 days, but I appreciate your help in trying to sort this out.

0 votes
KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 11, 2013

OK, 17 repositories should be fine, it may be to do with what you're doing with those repo's. Sorry for all the questions, it helps us narrow it down. Some more: are you using any particular views when this is happening, if so, which ones? Do you have 'All Files' selected? Are you using large selections with lots of large diffs or selecting ignored/clean/untracked files?

0 votes
fcorreia February 11, 2013

Embedded.

And both ST 1.5.6 and 1.5.7.1 report version 1.1.7.11.1 of Git.

0 votes
KieranA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 11, 2013

Just to try and narrow this down further before we do more thorough investigating, are you using system git/hg or embedded?

0 votes
fcorreia February 11, 2013

Version 1.5.6 is showing the same symptoms :(

Even when ST's windows is in the background, I frequently see it taking up 100% of the CPU.

I've also tried checking if there's a relation between the slowness, and disk activity (as reported by Activity Monitor), but I could establish none.

Also, ST is currently taking 1.13GB of memory (which is more than my IDE). Is this to be expected?

Anything else I can do to sort this out?

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events