SourceTree 1.4 pegs CPU much more than older versions

Hiten Parmar May 11, 2012

I've been finding that 1.4 will hit 100%+ CPU usage when switching ot the app after it has been dormant. Overall it was quicker to switch to the app and make a commit or two in the older app. Anyone else notice this?

3 answers

0 votes
HomeSmart August 2, 2012

I had no idea the App store wasn't going to send me anymore updates so no I wasn't updated to 1.5 yet, but am now. I'll take it through some test runs to see how things change. Thank you!

0 votes
HomeSmart August 1, 2012

I've noticed this behavior as well. However, I am not using drop box, I can definitely tell that the issue is it trying to refresh all the repos (21 of them). I don't remember though in previous versions it struggling to do that. Something I've noticed personally is I only have about 4-5 repos that get changed regularly which leaves me about 16 other repos that probably get a single file changed once a month? Maybe it would be possible to have things on separate cycles based on priority or pulling the recent activity / number of commits per repo and setting a refresh schedule based on that. So if a repo is getting 4 changes a day maybe have that refresh every time, however if a repo only gets a change every month maybe only refresh that one every 4 - 6 hours?

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.
August 2, 2012

Have you updated to 1.5 yet (you have to get this from http://sourcetreeapp.com we're not updating the app store any more since sandboxing)? This reduces the bookmarks overhead.

FYI SourceTree refreshes based on kernel file system events, and based on whether any remote repositories have new items ready to pull. The auto-refreshing behaviour can be controlled in Preferences if you'd prefer to turn it off.

0 votes
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.
May 12, 2012

I've been using 1.4 for a long time (I'm the author) and I haven't noticed any change in CPU usage. Indeed, nothing has deliberately changed in relation to the auto-refreshing behaviour in 1.4. The one change is that the bookmarks view is now a little more compact, so more items are visible at once and so there's a *potential* for more refreshing to be triggered if there are updates pending across more than one repo (SourceTree does not refresh until you switch back to avoid sucking CPU when it's in the background, but any queued kernel file events are then processed when you switch back). Do you notice a lot of your bookmarks going into the 'refreshing' state?

Hiten Parmar May 13, 2012

I think I told 1.4 to add bookmarks for all git repos on my computer. It added ~50, some of which are in a Dropbox folder. When SourceTree opens/refreshes it seems to update files in all the repos which cause Dropbox to activate. Not sure but this could be why it feels very laggy.

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.
May 13, 2012

It's not a good idea to put hg/git repos in a Dropbox folder. Every git / hg command, even read-only ones, creates temporary files (lock files and stream files) which would trigger Dropbox to think something had changed. Dropbox listens in on kernel file events just like SourceTree does, it's possible they could get into a bit of a ping-pong situation here.

You should use remotes to sync changes between machines.

Hiten Parmar May 13, 2012

I agree. I'm taking those repos out of Dropbox.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events