I recently updated to Sourcetree 2.7 (144) and I've noticed very high CPU load when operating on a Bitbucket HTTPS git repo - just typical commits and pushes.
It first came to my attention when I noticed the fan on my Mac OS High Sierra 10.13.2 machine was blasting after using Sourcetree for just a while. The CPU load in Activity Monitor showed >150%.
Even when it was idle, the CPU load would drift between 60-150%.
The machine specs are MacBook Pro, 2.8 GHz Core i7, 16 GB RAM, 185GB of free disk space on a 1TB SSD.
I've loved SourceTree for a long time, but this issue provided an opportunity to check out the upcoming Tower 3, and I have to be honest, I'm not sure I'll come back to SourceTree even if Atlassian ever decides to take this seriously and fix it. The new Tower is a pure joy to use. SourceTree could stand to take some cues.
I've identified a [the?] primary source of spins for our next major update, which just started internal alphas. The overall issue of performance is definitely not being ignored; it's challenging for our small team to balance responding to everyone and providing details while debugging reports and doing feature development. We appreciate your patience and enthusiasm and are working hard to this resolve pain point.
Senior Mac Developer, Sourcetree
Thanks, Brian. It seems to me that performance should be your primary concern. I'm now trialing Tower because of this - which is a shame because I think the SourceTree UI is great.
If you could keep us up to date with progress then I think you'll keep us all.
@bgannin I thought I would give the 3.0 Beta a try (196) and I see sustained high cpu use still, but it is less than it used to be. It was 90% now it is 35%, but I also got a significantly more powerful MacBook pro, so I don't know if the software or hardware is to blame for the improvement. At any rate, sourcetree continues to be the main battery drain on my laptop.
Do you have any more updates you can provide?
@bganninThis is insane. Your product has been unusable on Mac for almost a year now. Why even bother allowing people to download it? Why pretend that it works?
How many newbie users are running your software and thinking they need to buy a new computer? It's just unethical at this point. Your software is critically flawed on Mac - you should at least tell Mac users it's broken before you allow them to use it.
This appears to still be the case on 2.7 build 152, High Sierra. Unlike the initial poster, I see the symptom with SSH repositories present, so it is not specific to HTTPS. It wastes approximately 100% of one CPU all the time while running, idle. Ample disk, ample RAM, a couple of versions back there is no such problem, so I don't think there is anything about the machine causing this problem, but rather only a defect in the current source tree. This is... not ideal.
Unfortunately the only workaround I've found for this is to use a different Git tool when operating on battery.
I've installed build 152 - and while it seems a bit better, there is still what seems like a high idle CPU around 60%. Additionally, I noticed spindump firing up after running SourceTree. The log file indicated a high rate of idle wakeups:
Date/Time: 2018-01-12 14:22:36.973266 -0500
OS Version: Mac OS X 10.13.2 (Build 17C205)
Report Version: 19
Version: 2.7 (152)
Parent: launchd 
Wakeups: 45001 wakeups over the last 6 seconds (7027 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds
Action taken: none
Hardware model: MacBookPro11,5
Active cpus: 8
Fan speed: 3539 rpm
Powerstats for: Sourcetree 
Start time: 2018-01-12 14:22:40 -0500
End time: 2018-01-12 14:22:42 -0500
Microstackshots: 3 samples (100%)
Primary state: 1 samples Frontmost App, Kernel mode, Effective Thread QoS User Interactive, Requested Thread QoS User Interactive, Override Thread QoS Unspecified
User Activity: 0 samples Idle, 3 samples Active
Power Source: 0 samples on Battery, 3 samples on AC
2 NSApplicationMain + 804 (AppKit) [0x7fff54ee0f1a]
2 -[NSApplication run] + 764 (AppKit) [0x7fff54f11d6d]
2 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 (AppKit) [0x7fff556b2b4c]
2 _DPSNextEvent + 2085 (AppKit) [0x7fff54f1cf5f]
2 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (HIToolbox) [0x7fff56c51914]
2 ReceiveNextEventCommon + 613 (HIToolbox) [0x7fff56c51b96]
2 RunCurrentEventLoopInMode + 286 (HIToolbox) [0x7fff56c51e26]
2 CFRunLoopRunSpecific + 483 (CoreFoundation) [0x7fff57939d23]
1 __CFRunLoopRun + 1654 (CoreFoundation) [0x7fff5793a626]
1 _kernelrpc_mach_port_insert_member_trap + 10 (libsystem_kernel.dylib) [0x7fff7f37f762]
1 __CFRunLoopRun + 2427 (CoreFoundation) [0x7fff5793a92b]
1 __CFRunLoopDoTimers + 346 (CoreFoundation) [0x7fff5794332a]
1 __CFRunLoopDoTimer + 1822 (CoreFoundation) [0x7fff57943afe]
1 __CFRepositionTimerInMode + 135 (CoreFoundation) [0x7fff5790e1b7]
1 __CFArmNextTimerInMode + 621 (CoreFoundation) [0x7fff5790e66d]
1 <User mode>
1 _pthread_wqthread + 1387 (libsystem_pthread.dylib) [0x7fff7f4c41ca]
1 _dispatch_worker_thread3 + 101 (libdispatch.dylib) [0x7fff7f2016ed]
1 _dispatch_root_queue_drain + 515 (libdispatch.dylib) [0x7fff7f201941]
1 _dispatch_source_invoke + 620 (libdispatch.dylib) [0x7fff7f202018]
1 _dispatch_continuation_pop + 472 (libdispatch.dylib) [0x7fff7f212e76]
1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff7f1ffd50]
1 ??? (Sourcetree + 2746683) [0x102eb693b]
1 ??? (Sourcetree + 2747263) [0x102eb6b7f]
1 ??? (Sourcetree + 2747605) [0x102eb6cd5]
1 ??? (Sourcetree + 732931) [0x102ccaf03]
1 ??? (Sourcetree + 731468) [0x102cca94c]
1 ??? (Sourcetree + 729390) [0x102cca12e]
1 ??? (Sourcetree + 1590826) [0x102d9c62a]
1 ??? (Sourcetree + 1590312) [0x102d9c428]
1 ??? (Sourcetree + 1589609) [0x102d9c169]
1 ??? (Sourcetree + 1588912) [0x102d9beb0]
1 <User mode, Effective Thread QoS Default, Requested Thread QoS Default>
0x102c18000 - 0x102fb3fff com.torusknot.SourceTreeNotMAS 2.7 (152) <BDA3F21B-4C84-312A-93C9-F5FAD260A32E> /Applications/SourceTree.app/Contents/MacOS/Sourcetree
0x7fff54edb000 - 0x7fff55d38fff com.apple.AppKit 6.9 (1561.20.106) <7A71ACCF-2DF5-3557-BB22-3A9FC9F71CCF> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x7fff56c22000 - 0x7fff56f27ff7 com.apple.HIToolbox 2.1.1 <ADBE7A1B-0402-369C-A6F3-494E8CACD619> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x7fff578b5000 - 0x7fff57d55fff com.apple.CoreFoundation 6.9 (1450.16) <23F8373A-FA3F-37A2-BA5B-70061BFCCD21> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7fff7f1fe000 - 0x7fff7f237ff7 libdispatch.dylib (913.30.4) <7D0E3183-282B-3FEE-A734-2C0ADC092084> /usr/lib/system/libdispatch.dylib
0x7fff7f36d000 - 0x7fff7f392ff7 libsystem_kernel.dylib (4570.31.3) <D2E842AA-3B8D-31BF-8234-8C1BE11CFE32> /usr/lib/system/libsystem_kernel.dylib
0x7fff7f4c1000 - 0x7fff7f4ccfff libsystem_pthread.dylib (301.30.1) <ABA848E1-6978-3B42-A3A7-608B2C36FA93> /usr/lib/system/libsystem_pthread.dylib
Hi @bgannin I'm also experiencing this problem on build 152. The last few days I've noticed my CPU even sitting as high as 100%. As far as I can tell from using Activity Monitor's "Sample Process" tool, it's all in the NS drawing API, and primarily occurs when I have a repository workspace window open (not just the repo browser). And restarting SourceTree only brings it down from 100% to nearer 30-40%.
It's been almost 2 months since your above message. Can you please provide an update? This issue makes it tough to work without being plugged into the wall outlet, since it drains the battery.
I noticed that the issue that appears to be tracking this problem (or at least a similar one) is prioritized as "low":
An issue closed as a duplicate was marked as "highest":
The severity rating is similarly downgraded from "major" to "minor".
Any chance this slipped under the PM radar and should have been re-prioritized higher? Or, if there's a different ticket open for this, could you advise on the issue number?
Hi @bgannin - I installed and launched 2.7.3 (169) filled with hope that this would be resolved. It seemed at first to be keeping a low CPU usage, and it did if I only used the Repository Browser window. But within moments of opening any repository's window it crept back to 100% and hovered there.
I like this app. I like that my team uses the same tool. I want to see this fixed.
Let's talk. Where's your research led so far?
Here's what I've found:
Tangentially, I noticed a while back that there was a sort of automatic filesystem refresh that was added. Before that, I believe it would refresh when I returned from another application, or when I manually requested it. Now it seems to do so even in the middle of reading through a diff (which can be somewhat annoying, but I digress). I mention it in case it's related. The brief spike I noticed in the tiny repository - if related to the longer spike in a large repository - could be caused by the same code. I'm picturing a possible cascade of collection or visual updates triggered from the filesystem refresh, that never quite finishes before the next auto-refresh is started.
Using the Mac Activity Monitor and the "Sample Process" utility on Sourcetree, it appears all the samples fall in NS and CoreFoundation calls from, for example, mach_msg_trap. I'm not an expert in the Mach kernel, so I can't add any further insight here. But I figured it was worth mentioning along with the observations above.
Lastly, are there any other suggestions you have to eliminate the CPU issue? Do we need to reinstall, clear a cache, upgrade git, downgrade, or anything else that you've tried that helped?
How can this still be an issue? It was said to be investigated and a prioritized part of the upcoming releases over six months ago?
Ive downgraded to 2.6.3 to solve this, there seems to be pretty little hope even for a timeline when this could be solved. Im starting to look into switching to Tower...
Hey, as a hint for @bgannin, who may or may not even be paying attention, I learned that the CPU doesn't spike while the little gear menu in the top-right of the main bookmarks listing window is open. Opening that menu causes SourceTree to immediately drop down to typical idle CPU usage levels, and closing it makes SourceTree immediately spike back up to 100%.
Happening still on
- macOS 10.13.3 (17D47), MBP 15" Retina 2015, 2.7GHz 16G RAM
- with SourceTree 2.7.1 (159) git-embedded 2.5.1 git-lfs 2.3.4
CPU usage for SourceTree process won't go under 40%, with just 1 repo window open, git+ssh from bitbucket.org.
I tried system git (2.6) and different other repositories. Waited for 15min to "chill down", but still no less than 40% CPU. Laptop fan is blasting continuously...
I can't use the app anymore. I'll do the archive-download of an older version ...
Too bad, it was such a great app about 1 year ago, when it wasn't probably bloated with all the new fancy (useless?) features :-(
A vulnerability has been published today in regards to Sourcetree for Windows. The goal of this article is to give you a summary of information we have gathered from Atlassian Community as a st...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event