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!

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. 

@Al-Mothafar I have local repositories as well. It's the .gitconfig-file that I was referring to (which is remote).

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