Sourcetree 1.0.3.0 is slow to become responsive

[thomthom]

Just updated Sourcetree 1.0.3.0 that supports Mercurial and imported all my repositories (54 - Hg and Git). However, I find that Sourcetree is now very slow. It appear to be waiting to update the status of all the repos.

Now, I can understand if the UI information in the sidebar might be slow to update everything - that it could be checking the status of each repo. But when I doubleclick a repo to start using it I find that I need to wait for the sidebar to complete its thing before I can start working with the repo I clicked.

This is a show-stopper for me. All to slow. It's be nice if the sidebar could do its thing in the background allowing me to get started on the repo I want to work on immediatly as I open it.

Is there any setting that might somewhat address this issue?

[stevestreeting · Accepted solution]

Hmm, the sidebar does actually do its work in the background, except for the final rendering which has to be in the UI thread - that's why you see a spinner there (that's the only bit running in the UI thread).

I have about 40 bookmarked repositories here (mixture of hg and git) and the main delay is at startup, and that can be reduced by collapsing tree view elements in the bookmarks view if you don't need to see them all. Opening a new tab here takes a couple of seconds - this is a Core 2 Quad from 2010 with a regular HDD and 4GB RAM BTW, not a beast.

Example: http://screencast.com/t/TZvWRhBVer (this is reasonably sized repository)

What level of delay you're talking about - is it more than this, and what are the environmental conditions such as the size of the repo, amount of free RAM etc?

[thomthom]

I recorded a video of what I experience on my system: http://youtu.be/V_GnB17gJJE

My repositories aren't that big. If you want to inspect them they are mostly all public on BitBucket (https://bitbucket.org/thomthom/) and GitHub (https://github.com/thomthom/)

My system is a QuadCore 3Ghz system, 8 GB ram.

Repos load fine and quick once the sidebar is done populating.

[stevestreeting]

Ah I see, so what you're seeing there is actually the startup delay. This was confusing because I refer to the side panel *inside* each tab as 'the sidebar', and once the initial refresh of the bookmark list is done this is very quick, as you showed.

I believe I've traced this slowness down to the tree control I've had to use because WPF's own tree control doesn't support multi-selection, and I haven't been able to track that down completely yet. It may also be down to the sheer number of bookmarks and the queue of actions solely on first opening - .Net encourages you not to manually schedule threads but I may have to tweak it for this particular case.

So yes, I know what you mean now - it's only a startup issue though, once you've gone through this one-off you should find things snappier. Grouping your repositories in folders in the bookmarks list and collapsing the ones you don't use much can speed things up too. I will be trying to address this in a future version - the current behaviour is no different to previous versions, I just guess you have more bookmarks now.

[thomthom]

Yea, when I added my Mercurial repos I got a longer list and then the slowdown was noticed. I tend to close and open the SourceTree window. It's a habbit I got - keeping the number of open windows to a minimum.

Just installed the 1.0.6 update and the startup performance seem to be much better! Thank you very much!