Its going to be very strange i am using 2.6.10 version  & its going in not responding 

Hi

While I'm sure we've not fixed everything for everyone it is heartening to receive positive feedback on your current experiences.

Cheers

Mike

Been using 2.6.10.0 for a while and it's great. No more lock ups, woo! Got a few small problems that I need to report but will open new issues.

Wow! Just tried 2.6.10! Flying along! Nice!

Been great for me since 2.3.1.0. Thanks for your continual efforts.

Recent versions seem good here.  Thanks!

@mminns our team is using 2.6.10.0 and works great!!

I'm happy to say that the last several versions have been very good for me. Fast enough and reliable. Thanks!

Hi

We have continued to make incremental improvements. Is anyone able to give us an opinion on 2.6.10?

Thanks

Mike

2.5.5 still sucks in our environment

Seconded - 2.5.5 works well

2.3 was nearly unusable for me, 2.5.5 is definitely much better.

2.3.1.0 is so slow, that I finally learned to do more and more stuff on the command line - yay.

I mean, it is a free tool, so thanks for that. But in this state it is simply unusable for so many devs out there.

birger.schuette We're getting ready to release v2.5 (there will be a blog post), which includes an enterprise-ready offline MSI installer assuming you have a Bitbucket server instance to authenticate to.

@Mike Corsaro
Thanks for the information. As I wrote, we still use version 1.6.20 due to the lack of offline usability and until Atlassian releases an official version for secure enterprise use, we have to solve the ongoing problems. I still wanted to document it here, because some of our developers found this ticket for their performance issue and so I thought that others could also be interested...

birger.schuette that issue has been fixed in version 1.9.7, released in Dec of 2016.

We still use version 1.6.20.0, because of security reasons, our developers will never get direct access to the internet!
(see SRCTREEWIN-5417, SRCTREE-3593)

Since a few weeks (apparently a while after we changed the os to Windows 10 build 1709), the performance has decreased dramatically. Switching between individual projects sometimes takes more than 60 seconds. After more and more developers confirmed the same behavior, I tortured Procmon of sysinternals. After analysing the result I noticed a repeated access to the RuntimeBroker.exe. This one always resorted to dictionaries (.dic) at the path *%TEMP%.

I think the following article describes the reason of the performance problems:

WPF spell Checking uses Windows dictionaries and these dictionaries are globally referenced in the registry.

So I checked my registry key Global at HKEY_CURRENT_USER\Software\Microsoft\Spelling\Dictionaries.
The value of this key had grown up to more than 147 entries for Dictionaries in my Temp directory, which were for the most part no longer present.

Workaround (1.6.20.0)

After I removed this registry key, the performance improved significantly:

REG EXPORT HKEY_CURRENT_USER\SOFTWARE\Microsoft\Spelling\Dictionaries %TEMP%\Dictionaries_Global.reg
REG DELETE HKEY_CURRENT_USER\SOFTWARE\Microsoft\Spelling\Dictionaries /v _Global_ /f

Remarks

The deleted registry key initially contained an additional entry: C:\Users\MyName\AppData\Roaming\Microsoft\Office\16.0\8322c54b\Proofing\RoamingCustom.dic
This value was automatically reinserted when opening any Word document.

Open questions

• Why does SourceTree creates so many dictionary files with the same content in the temp folder? It seems to me, that it creates min. 1 file for every open project.

@Michael Minns

I have disabled libgit2 integration for a long time now, because it's much faster this way for me.

Just a sidenode: Whenever this "Loading xxx comments " message occurs, sourcetree selects some random commit way in the past. Sometimes even more than half a year old and in a completely unrelated branch.

It was not unusual for me to wait 30 seconds on any operation on a tiny project.

Running SourceTree as administrator made everything running smooth again for me, less than 1 second delay on any operation

Hello Everyone.

While, by our measures, we have made considerable improvements in performance across Sourcetree over the last year, we do continue to see it as a priority and to look for areas to improve. 

HI karl2074962297

Thanks for flagging that up. There a couple of things you can try.

In Tools/Options/General 
Set the 'log rows to fetch per load' to 0

In Tools/Options/Git
Disable libgit2 integration

Overall libgit2 provides better performance for read operations for git.exe but it is not consistent across all repositories and environments.

Ironically, thanks to this issue, I have switched fully to command-line git. 

Thanks for the new skill.

I was satisfied with the sourcetree performance for quite a time now. But with the latest update (2.4.8.0) I think there is a new performance-related issue:

Whenever I switch brachnes or checkout a new remote branch, it takes quite a while until sourcetree is ready. Today I checked out a new branch from remote. I got the message "Loading 516 commits to reach commit ...", which lasted for about 30 to 40 seconds. I already had the base of this branch checked out a while ago. And this branch definitively does not contain more than 500 commits since it was branched from its base. I understand there is some loading from remote servers involved, but sometimes this also happens when switching local branches.

Here's a good video showing the huge performance degradation of SourceTree:

https://youtu.be/eaKw1WPO5V8

It looks like the same issue is plaguing the Mac version as well.

Hello Team,

Any permanent fix for this. We are evaluating Gitkraken. Just to see when the fix will be available? Any updates would be helpful.

Note: I tried the resolution and it didnt work me. I am using Widnow 10 + 16 GB RAM and Source Tree 2.3.5.0

I confirm, version 2.3.5.0 with disabled LibGit2 works fine for me.

Just want to add that disabling LibGit2 worked for me as well. Night and day difference. I'm on Version 2.3.5.0

Anyone reading this, just go to https://www.sourcetreeapp.com/download-archives and download 1.9.13.7 (or your pre-2 version of choice).

I'm on version 2.3.5.0, disabling LibGit2 has worked for me as well.

Before, refreshing a repo would take over 10 seconds (independent of the number of commit lines being loaded).

Now it takes about 2 seconds.

So we disabled the gitlib2 integration this morning, and have had no slow downs since. I did do a before and after benchmark, and I would be happy to send that to anybody interested.

The major difference was that GetSummaryMs moved from 39860ms down to 923ms. (Other areas showed increase, but not on that magnitude.)

I found the same recently when going through comments on other tickets that were suggesting disabling LibGit2 integration (running on system Git 2.15.0)

Performance numbers generated by Repository > Benchmark Repo Performance feature can be easily compared.

Just chiming in as another user that has found LibGit2 unusable with SourceTree on large repos. The easiest way to see this is to open the Log/History view on startup with a large repo. In my case:

• LibGit2 takes ~30 seconds before anything is shown
• Disabled LibGit2 takes ~2 seconds to show

2.3.5.0 is working fine for me now. It's usable now . Thanks, team! I think I have LibGit2 disabled.

Michael Minns,   Thanks for the update. We will continue to be patient.

Whole team has moved back to 1.10 because of this issue

raycj 2.3.5..0 has a performance improvement around restarting/focusing Sourcetree with multiple tabs open. It is not intended to fix all performance issues. We are continuing to work on other areas of concern.

Still slow, even in 2.3.5, should we open another bug?

Ah, if you had requested a ETW trace a bit earlier I would've been happy to help out. Unfortunately, I've gone back to 1.9 now (and it works like a charm). Disabling libgit did help for a short while (30 minutes maybe?) before going back to being sluggish (the first time, disabling didn't stick (it was enabled when I checked again the next day), but the second time it did).

I did agonize a bit over going back, as I was worried about my settings and such. But the only thing that broke was that I had to do was change the ssh client from putty to openssh. Other than that, it remembered all my repos and everything works. (In case others are worried about going back to 1.9 as well).

andy840753121 See this guide for troubleshooting perf. Tl;dr: try disabling Libgit, if that doesn't work please do a ETW trace and email me that. Thanks.

Same problems as all of the users above.

Ironically, it doesn't have any problem asking me every time how likely I am to recommend Sourcetree.

I'm spending 15 minutes a day looking at the various screens waiting for them to load so I can do something.

Prior to the recent 2.x updates performance was never an issue

I have been using SourceTree a lot less than I used to ever since the 2.0 update crippled it. One thing I found that helps that I haven't seen mentioned is to turn off the automatic refresh in the options. I turn off "Refresh automatically when files change" and "Check default remotes every 10 minutes". Turning off those options have been the only thing so far that has remotely improved the performance. All other recommendations did nothing for me. It is a little more of an inconvenience having to manually refresh but at least it is somewhat usable now. 

@Joel I have fiber connection with 120Mbps download, 60Mbps upload, and the problem also happens for local repositories.

Hey SourceTree guys.   If it helps, you're welcome to TeamViewer into my PC and see it for yourself.  

Perhaps this is related SRCTREEWIN-5536. We have a pretty slow connection to the user home folder and since it keeps reading these files all the time it may cause problems. Still no way to change the location of these files?

I've had it with SourceTree. Eclipse is 100x faster (that's not an exaggeration, I estimate that Eclipse really can accomplish a task that takes SourceTree 3-20 seconds to complete in 30 to 200 ms). Too bad, since SourceTree has some nice features that Eclipse doesn't have.

Here is my experience in my company.
To sum it up we experience both cases.

On my computer Source Tree performances are i think a litle better than 1.9.
I use LibGit2.

But I have colleagues who had to return to Source Tree 1.9 as said by others.
It was simply unusable.

Well all have repositories on SSD, same hardware.

I've the same issue,  and yes. I've tried all the recommendations, and then some.

I decided to rebuild my WIndows 10 PC 3 days ago, so can also confirm that this is a fresh install of SourceTree on a fresh install of Windows, with a copy of the GIT repository pulled down from BitBucket.   it takes roughly 10-30 seconds between clicking a button in SourceTree, and the app completing it's action. 

For example, I have to click commit 3-4 times before it becomes responsive.

It's unusable.

The statement that 2.x is "faster for some"  is complete fabrication.

There are no users that I know who say 2.x is faster in any way than 1.9.

It's time to scrap the 2.x code base, revert to 1.9 and start over. 

@mcorsaro I just need to provide more feedback, I hope will be helpful, but first please don't ask me to do more experiments because I tried all solutions and got tired and wasted a lot of time, so I ended with uninstalling it at all and hit back to the better version 1.10.x  

I did full cleanup and reinstalled it was not helpful, I did disabled  LibGit2 and same issues stays, one day I was unable to even commit for 2 minutes, I noticed that the settings were still with LibGit2 disabled, yes sometimes I see it unchecked but if you wait for a minutes you will see that Application got the setting window updated and you see the correct settings, the setting already stored and not got upset.

Most my repositories are from GitHub and BitBucket, and the issue happens on both, It is was just getting worse by the time, restart it make it fast for a few minutes then the problem happened again.

Short story, SourceTree 2.x is suffering serious issues, and disabling LibGit2 does not work at all.

rleeson Your settings are getting reset after you reload a tab? Do all your settings get reset? While the lockup happens, are there any git process running? Does it just happen with a specific repo, or any repo? Does it happen when you just have a single tab open?

Additionally, if you're able to reproduce the problem: could you perform an ETW trace using UI for ETW (you can find a simple guide here). Make sure you close all programs other than Sourcetree when starting. Be aware that some personal info (such as file names, but not the contents) may be collected from the trace as part of disk I/O monitoring. After doing the trace, please email me the file. This will help determine the problem.

@Mike Corsaro please read above, this has been tried and is unsuccessful.  After reinstalls and clearing old settings and program data, this is not successful.  The setting to disable LibGit2 does not work.  The setting lasts until the next time a tab rescans a repository, then it locks up SourceTree, I'm guessing until the request times out, as it lasts about 30 seconds.  I and other people in this thread have documented this behavior, and offered more information if that would somehow help.  Please don't fall back on assuming the disable switch works across the board, it might in some situations, but there is a clear defect with this functionality in others.

anton74 We've mentioned it before, but yes – please try disabling LibGit2 if you experience long delays or constant progress indicators. This is a known issue. In most cases, LibGit2 should offer a significant speed-up but we've found that sometimes it does not.

Per this article, under the header "Blazing Fast Performance", the LibGit2 handler was added with SourceTree version 2.

Possibly it's a bug of LibGitSharp2. Did SourceTree 1.9 use another version?

RepositoryManager.CheckSummary is very slow also.

libgit2 git_status_list_new is really slow

I was hesitant, but after all the praise above I finally went back to 1.9.13.7. Holy cow! Now this is what I call an upgrade! SourceTree 1.9 is blazing fast, compared to the new version. It looks sharp, works fast and has all the features I need. And the bookmarks menu is so much better.

My sincere recomendation for both Windows and macOS: stick to the old versions. They were good. Upgrades only bring pain and suffering.

Sourcetree 2.x is horribly slow for me too. My blood pressure decreased 30% immediately when I switched back to 1.9.13.7. Old Sourcetree is very good product.

I returned back to 1.10.23.1 is really got a big difference in performance, I really suggest to drop version 2.x at all, it is just a rubbish, it is the shame for Atlassian.

Wow, the performance gain by switching back to 1.9 is insane!

"Unusably slow" sums it well. I'm shouting expletives every day in the office now. After this and similar shameful experience with JRASERVER-1369 I've lost hope for Atlassian. It's amazing how they took a good app and then put time and money into making it so much worse.

I went back to 1.9.13.7 six weeks ago and haven't had any performance issues. You can download it here: https://www.sourcetreeapp.com/download-archives

so slow that i cant use it recently. I only opened a small repo with 10 commits and 50 files, still very slow.

I ended up buying GitKraken because this was such an issue in my day to day work: https://www.gitkraken.com/

+1 for "unusably slow" actually, I believe it will be better if devs here go revert until 1.9 version and go up again, it is ok to step back really, anyway personally I'm trying alternatives right now, once I get something useful, for sure I'll quit this SourceTree sadly, after 2 years of using it.

same here

>Can I petition for this issue to be renamed from "annoying slow" to "unusably slow"?

I'll second that. I've been on an older version of SourceTree for a while now specifically because of this issue. I can't get my work done with the current releases because they're so slow.

Can I petition for this issue to be renamed from "annoying slow" to "unusably slow"? I can only imagine how many people have given up on the product, and it sours the Atlassian name. Terribly unfortunate for a company that puts out some great products.

> I really hope you fix this stupid issue, I really recommend you to push all efforts to fix this, because this will kick half of the users out of this application.

Agreed, I've tried other tools, but source tree is simply the best out there for me. Currently have to use 1.9.x version. I've tried disabling libgit2, but performance issue appeared once again after a while.

What's making me sad, that the issue was created on June, 1 and still not resolved...

The experience with SourceTree become horrible, I tried GitKraken the application was so light and super fast but the UI is confusing, I really hope you fix this stupid issue, I really recommend you to push all efforts to fix this, because this will kick half of the users out of this application.

I see that too. I did – as @michael minns suggested – delete all but the latest of the sourcetree.exe_url_... folders. Did not help. Yesterday evening I checked the "disable libgit2" checkbox, today in the moring it was unchecked again ...

I can confirm Ryans observation. I checked the disable box yesterday, it was unchecked again this morning.

New update, I've been able to reproduce an error with SourceTree around (at least) this setting.  I let the app sit (3 times now) for long enough to perform an auto poll of the remote for updates.  When it does the auto-remote check, the setting seems to be ignored/temporarily cleared.  I opened the Options dialog and it shows the box unchecked and behaves like it's unchecked.  With the dialog still open, I went to my settings file and confirmed the dialog was still set to true.  When I go back and try to interact with the settings dialog, it hangs then closes.  When I reopen it, the setting is set again and it functions well again.  Seems like there is some problem with settings state persistence here, let me know if you need more detail.

I checked the setting before and after clearing the %localappdata% folder locations, and the setting was persistent across application close/open events.  After the clear of those old settings folders, I'll look and see after the next update if the setting reverts.

We will have a look at the re-setting of user configuration.

in the meantime it should help to delete all the %localappdata%\Atlassian\Sourcetree.exe_url_{hash} folders for versions other than the one you are currently running.

Can confirm it keeps clearing. It's even clearing each time I close source tree! Going to try reinstalling. This isn't on! Can't use Source tree at all. Takes 30s to update file status.

For anyone looking at this, please make sure the "Disable LibGit2" is actually off after saving the option.  I noticed that the setting gets cleared every time SourceTree updates, so it goes back to being disabled.  Pretty poor user experience for settings you make to be arbitrarily cleared across updates.

Embedded git / system git, LibGit2 enabled / disabled – whatever I choose doesn't make much difference for me either. SourceTree is getting slower with each version and now, testing on simple repo refresh action, it feels an order of magnitude slower than the JavaScript based GitHub Desktop. Which is a shame.

Disabling LibGit2 was not helpful for me.

This should get a performance label, for what it's worth.

Just want to say Ryan Leeson's Workaround to disable the LibGit2 integration works wonders on the performance of Sourcetree. My Repo is on a Samsung 960 Evo PCIe SSD, so disk performance is no issue here. See the two repo performance benchmarks:

LibGit2-Enabled.json

^{LibGit2-Disabled.json}

I was experiencing what is seemingly the same issue with the commit history constantly refreshing.  After trying the suggestion from @Mike Corsaro, when I switch to another commit in a tab, the UI responds again.  It appears it can stop whatever is running in the background after disabling the LibGit2 integration (check the box at Tools -> Options -> Disable LibGit2 integration.).

@Mike Corsaro (oh I can't mention :/ ) 

The issue is random, but happens, as I said it is sometimes, the avg here is about 15 - 20 seconds for each action (refresh, fetch, reading changes, and so on), btw it is really annoying here when I see uncommitted changes on History, and I can't commit them at all because it shows nothing in File Status tab, the experience become horrible.

I have 8 active tabs usually and made no configuration, it is just as it is as the same as a new installation.

My connection is really fast, fiber connection with 90Mpbs download, 50Mbps upload, with abound 148ms latency to github.com, but most of the times I'm using my local server anyway about less than 1ms latency and 200Mbps connection.

Hi Everyone, 

So I have had this issue for the last 3 versions. Can't remember the specific version numbers by it was ever since updating to version 2. Tried everything suggested (I think) and then decided to wipe out all user and global settings directories and reinstall. Basically did a search in C:\Users\<username>\AppData and %allusersprofile% for anything resembling atlassian and sourcetree and renamed it (for safety). After that and reinstalling it all seems to be running fine. Not sure if this helps but thought it might help with working out what is happening....

almothafar26885896 What are you doing that takes 1 min? How many tabs do you have open? Have you tried disabling automatic refresh? Have you tried disabling LibGit?

It is still very very slow here, and seriously I'm looking for alternatives right now, the delay about 1 minute sometimes, I'm on windows 10 64-bit and now I'm on the version of 2.3.1.0 

I really loved SourceTree but I think I have to look for something else because this issue being here from old versions )2.0 or 2.1) and still no solution.

And I agree it is "a little" faster, but still so having really bad experience.

2.3.1.0 on Windows seems better than the last few releases but still not good. I have 13 tabs open and it's still sluggish and borderline unusable.

2.3.1 is better, but still not fast depending on the tab I have open.

I would not call it "extremely quick", but it's definitively much faster than previous versions. Even with LibGit (which seems to be reenabled with the update)

But also in 2.3.1 the number of open tabs seems to have a massive impact on the performance. If I start sourcetree with only one tab open, the repo history graph is rendered after about 2 seconds after the main window is shown. If I have several tabs (in my case 8) open at the start, the same graph needs nearly 20 seconds to render.

If you don't get the update automatically you can download it from https://downloads.atlassian.com/software/sourcetree/windows/ga/SourceTreeSetup-2.3.1.0.exe. It seems extremely quick to me, even loading diffs, viewing the log / history tab, adding existing repos.

2.3.1.0 is definitely feeling a lot snappier to me.

Good news for me this morning. An update was available to go to version 2.3.1.0.

It's been flying all morning... like a dream. Hopefully, it'll stay this way.

Is 2.3.1.0 Good for you all too?

Oh and there are a few ui colour scheme updates and a new SourceTree icon, so hey, that's pretty exciting anyway, right?

The performance problems that I was seeing went away when I closed down all repo tabs that I wasn't actively using. I now have to use SourceTree with only one repo open at a time.