SourceTree 1.4.4.2 on Lion 10.7.4 unacceptably slow during log refreshes & other git operations

[Paul Hoepfner-Homme]

At my company we are a very happy customers of JIRA. Recently I've been trying to pin down the best git GUI out there. I came across SourceTree and naturally, it being an Atlassian product, I gave it a shot.

I think it works great. It's very powerful and seems to have everything I need in a git GUI. I'm very pleased to have found one that is more user-friendly than Tower, and much more powerful than GitHub for Mac (which I'd been using previously).

However, increasingly as I get more experience with the software, I notice that it really bogs down my entire system for a number of its operations. In particular, refreshing the commit log and pulling from the remote tend to take seconds to complete - sometimes many seconds - and often during that time my MacBook Pro is almost completely out of service. My wireless trackpad's cursor becomes so jerky I can't really control it, and all other applications practically grind to a halt. My CPU fan goes on real high, too.

Being a programmer myself I am mystified as to why SourceTree is performing such CPU-intensive operations, and taking processing priority over all other processes (including the processing of my Bluetooth trackpad, it seems). In addition, I never notice any behaviour even remotely like this when using git from the command line - it's very fast and quite relaxed. Why should the GUI be so different in behaviour? What is so important that I'm prohibited from continuing my conversation on Skype or writing my e-mail until it completes?

Tower actually exhibits similar behaviour, which makes me wonder if this behaviour is intrinsic to git GUIs! However, SourceTree wins as far as duration of the OS slowdown goes, and unfortunately it really hampers the user experience to a point where I have to consider an alternative.

I hope someone can shed some light on this problem.

Thanks very much to Atlassian for an otherwise great product.

Paul

[Paul Hoepfner-Homme · Accepted solution]

Thanks to Steve Streeting's feedback, the solution to this problem is to use SourceTree 1.5 beta, available here.

This is the first git GUI I've used that has solved this weird problem! It's now much faster than GitHub for Mac and Tower (not to mention a better overall product, in my opinion). Great work!

[Matt Parlane]

I'm still having this problem using 1.5.3 on 10.8. Many operations like simply Cmd-Tabbing the app to the foreground lock up the whole machine and cause the mouse to freeze.

[Paul Hoepfner-Homme]

Hey Matt,

I actually ended up experiencing it again, even with the same version of SourceTree I mentioned above. It seemed to happen this one time after resuming my computer from standby, and it was already running. Just went back to "being slow" like it was in 1.4 - refocusing the app would cause the mouse cursor to freeze while it was doing all its refreshes, just like before.

I ended up fixing it simply by restarting the program, and it hasn't happened again since.

I'll upgrade to 1.5.3 and post again if I experience the same thing.

[Toby Griffiths]

I'm also having this problem with version 1.5.6 on OSX 10.8.2.

Causes everything on my machine to pretty much stop. Mouse movements are extremely jumpy, spotify playback is broken, etc. until the refresh has completed.

Any update on this problem?

[farmerpaul]

I'm using SourceTree 1.5.4, and, unfortunately, the behaviour described here crops up pretty reliably if the program has been running for a long enough time. Whenever it needs to do some kind of processing, the cursor gets jerky and I can tell the CPU is being intensively used.

When this happens, I don't see anything in my /var/log/system.log that appears to be related to SourceTree.

If I restart SourceTree, it operates fine again. Then after a day or two – maybe even a week, not sure what triggers it – this jerkiness returns.

It isn't as bad is it was before SourceTree 1.5, but it's still pretty annoying.

[Christopher Pickslay]

I've been using SourceTree for over a year, and 1.5.3 on Mountain Lion is the first I've experienced this problem, but it's happening consistently now. Basically freezes up the UI, pegs multiple CPU cores, and causes fans to spin on for a minute or so when focusing the app. I see a bunch of this in `/var/log/system.log` when it's happening:

Aug 16 21:39:45 macbook pro com.apple.launchd.peruser.501[159] Aug 16 21:39:51 macbook pro WindowServer[88]: CGXDisableUpdate: UI updates were forcibly disabled by application "SourceTree" for over 1.00 seconds. Server has re-enabled them.

Aug 16 21:39:55 macbook pro WindowServer[88]: reenable_update_for_connection: UI updates were finally reenabled by application "SourceTree" after 4.82 seconds (server forcibly re-enabled them after 1.00 seconds)

Aug 16 21:40:00 macbook pro WindowServer[88]: CGXDisableUpdate: UI updates were forcibly disabled by application "SourceTree" for over 1.00 seconds. Server has re-enabled them.

Aug 16 21:40:14 macbook pro WindowServer[88]: disable_update_likely_unbalanced: UI updates still disabled by application "SourceTree" after 15.00 seconds (server forcibly re-enabled them after 1.00 seconds). Likely an unbalanced disableUpdate call.

Aug 16 21:40:15 macbook pro WindowServer[88]: reenable_update_for_connection: UI updates were finally reenabled by application "SourceTree" after 15.91 seconds (server forcibly re-enabled them after 1.00 seconds)

Aug 16 21:40:33 macbook pro WindowServer[88]: CGXDisableUpdate: UI updates were forcibly disabled by application "SourceTree" for over 1.00 seconds. Server has re-enabled them.

Aug 16 21:40:34 macbook pro WindowServer[88]: reenable_update_for_connection: UI updates were finally reenabled by application "SourceTree" after 1.50 seconds (server forcibly re-enabled them after 1.00 seconds)

Aug 16 21:40:37 macbook pro WindowServer[88]: CGXDisableUpdate: UI updates were forcibly disabled by application "SourceTree" for over 1.00 seconds. Server has re-enabled them.

Aug 16 21:40:38 macbook pro WindowServer[88]: reenable_update_for_connection: UI updates were finally reenabled by application "SourceTree" after 1.79 seconds (server forcibly re-enabled them after 1.00 seconds)