After running for a while, SourceTree operations stall cursor movement and incur high CPU load

[farmerpaul]

I'm using SourceTree 1.5.4 on OS X Lion 10.7.4, and, unfortunately, the behaviour described here crops up pretty reliably if the program has been running for a long enough time. Whenever SourceTree needs to do some kind of processing (typically, refreshing the git log), the cursor gets jerky and I can tell the CPU is being intensively used.

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.

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

This behaviour isn't quite as bad is it was before SourceTree 1.5 came out, but still frequent and annoying enough that it's prompted me to post here.

[farmerpaul · Accepted solution]

Sorry I never updated anyone about this - SourceTree has been performing fine for the last few versions. Since at least January I've seen no major performance issues. So I believe some of the issues I was having have been fixed some time ago. Not sure what could be happening in Thomas' case, however.

[adamduren]

SourceTree causing my CPU to hover around 100% and takes up 2.5GB on average. It's killing my battery life. Any ideas? Running version 1.6.25.0 with one project tab open on Windows 10 with an i7 processor and 16GB ram. 

sourcetree battery usage.PNG

[Jared Qin]

Still cause my Mac's fans running.

[Marcel Müller]

Me the same since a couple of weeks. First i though on a mac osx problem but i get the slow down only while SourceTree is open. Please fix it, at the moment i have to use terminal or GitX :(

[Matt Sundquist]

Confirming the same issue. SourceTree v1.7.3. OSX Lion 10.7.5. MacBookPro 2.4GHz w/ 4GB RAM. Mostly default settings, about 20 hg repos; 3-4 of which contain sub-repos.

It normally works beautifully. I launch around 9AM and have it running all day. At around 3-4PM, every day almost as if by clockwork, SourceTree starts becoming unbearable - consuming the entire CPU to the point where the entire system in unresponsive until spins down. I let it sit for 10-20 minutes, and eventually things return to normal and I can utilize both SourceTree and the system as normal.

It's hard to tell for sure due to the unresponsive system, but the issue seems to be related to the number of threads launched at any given time. Sometimes the thread count is over 90. In it's normal state, the thread count never seems to exceed 30, and when not being used, less than 10 threads.
(Unresponsive) Real Mem: 994M, Private Mem: 763M, Virtual Mem: 1.57GB; Threads: 90+
(Fresh launch) Real Mem: 46.7M, Private Mem: 23.4M, Virtual Mem: 429M.

[Marcel Müller]

I've got the same issue in daily business. No UI/Mouse Interaction while using SourceTree since the last Update.

[Thomas Hauk]

This has started happening to me as well since I moved to a newer iMac running 10.8, but that could be a coincidence. My CPU load jumps up as high as 120%, but only when it's doing operations, e.g. the UI/mouse is responsive until I perform an action like click the Commit button, in which case it goes nuts for a few seconds and then calms down again. I normally keep SourceTree open for days at a time as well.

[stevestreeting]

The bookmarks shouldn't make any difference any more, since they're throttled now (for the record, I have ~50 bookmarks so 14 is not a big deal). I'm just not sure what's causing all those tasks to kick off then.

[farmerpaul]

These days I only have one repo window open. Sometimes I have 3 or so, but this week I've been focused on just one project. I do also have my bookmarks window open, but it doesn't need to be; never occurred to me that it would be using much in the way of resources. I've got 14 bookmarks. I'll try keeping that closed and see if it makes any difference.

[stevestreeting]

Thanks for the sample. It looks like a lot of tasks got kicked off, do you have a lot of repo windows open? I did some work on throttling the bookmarks view when a lot of pending updates had been queued (ST doesn't refresh in the background to avoid sucking time, it waits until you re-activate it), but right now the repo windows aren't throttled, on the assumption that while you might have 50+ bookmarks, you won't have that many open repo windows.

[farmerpaul]

I've been using SourceTree heavily over the last couple days (since I posted my comment above) and it has been performing quite well. (It's really a great app and helps my productivity tons - thanks, btw.)

Then today, out of the blue, I activate the app after having been busy in Skype and Chrome for a while, and it totally slows my entire system right down. My cursor was jerky for a period of about 2 minutes, and my CPU fan steadily got louder and louder; I could barely manage to get Activity Monitor to open so that I could get another sampling of the program to send to you - but I still did!

So here it is: Sample of SourceTree.txt

[farmerpaul]

Hi Steve,

It's been a long time since the last time this happened, but today after the weekend it started happening again. In fact it seems as if not using the program for a couple days (but keeping it running) often prompts this behaviour. It didn't happen once during the week when I was using it every day.

I watched Activity Monitor while SourceTree was doing its refreshes and causing the mouse cursor to lock up, and saw CPU use levels of between 80% and 100% – and it even went up to 108% at one point! (Certainly a bug in Activity Monitor's polling code?) The memory use is between 130 and 155 MB right now.

I've attached a sampling of the process while clicking the "Refresh" action, which causes this high CPU load and locking up of the cursor (Sample of SourceTree.txt).

Thanks,

Paul

[stevestreeting]

When this happens, what does Activity Monitor say about about the SourceTree process, in terms of CPU / memory? If you have the 'Sample Process' option available it would be useful to try using it and attach the info here.