Sourcetree 2.7 (144): High CPU load on Mac OS High Sierra 10.13.2

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.

sourcetree-high-cpu-mac-high-sierra.png

38 answers

This widget could not be displayed.

For the love of god please fix this. 

Yeah this is driving me mad. My usually good battery was dead within 2 hours of me arriving at a conference because I forgot to kill sourcetree. Its #1 on 'Significant battery usage'. 

When its running (and not even in use) fans are going full speed and CPU spikes. 

Seriously! SourceTree has been practically unusable for over 6 months now.

I highly recommend checking out Tower 3. This issue forced me away from SourceTree and I highly doubt it's getting fixed anytime soon.

This widget could not be displayed.

I removed the version 2.7 of SourceTree and downgrade to 2.5.3. This version works also with high sierra  

https://www.sourcetreeapp.com/download-archives

I've downgraded to 2.6.3 (134) and it is working for me on High Sierra 10.13.2.

This was a great suggestion - works for me as well.

2.6.3(134) works fine too on Mac OS Sierra 10.12.6

LOL, the sneaky bastard updated itself to the crappy 2.7 version again (after a restart) and I only noticed by after I got annoyed by tie the sound of the vent blasting away continuously ...

Thanks for the archive link! I'm also having issues since 2.7, not cool at all! Downgrading asap.

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.

This widget could not be displayed.

I've been noticing SourceTree causing slowness on my Mac too.

SourceTree: 2.7 (144)

OS: OSX Sierra (10.12.6)

Processor: 2Ghz Intel Core i7

Memory: 16GB 1333 Mhz DDR3

Screen Shot 2018-01-01 at 5.47.42 PM.png

This widget could not be displayed.

Same here, %CPU always between 80 and 100%, decreasing battery life significantly. Restart doesn't help, I have to keep Sourcetree turned off.

Screen Shot 2018-07-10 at 16.52.32.pngIt uses more power than Chrome and PhpStorm combined! 

This widget could not be displayed.

Hi everyone,

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.

Brian Ganninger
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.

Thanks again.

Hi @Brian Ganninger. If you guys are short in resources, you could just go open source and this kind of stuff would get solved in 1 day.

I know you might not be the decision maker here, but you have more influence than me for sure.

@Brian Ganninger I'm so glad that this issue is not being ignored - my team has been stranded on 2.6.3 for months.  Can you tell us what version this fix will land in so that I can try it when it is released?  2.8? 3.0?

Hi @Brian Ganninger,

Thanks for the good news... is there a ticket where we can watch progress? Mobile team and battery life is at stake for us.

This widget could not be displayed.

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.

This widget could not be displayed.

Well this is a depressing #metoo

Screenshot 2018-03-29 21.20.59.png

Fix this please - it's killing my MBP!

This widget could not be displayed.

We've had a couple reports about this and will investigate shortly. Thanks for the info.

Brian Ganninger
Senior Mac Developer, Sourcetree

Also experiencing this, but only when the interface is visible. If Sourcetree is running, but no windows are open, then it will eventually lower it's CPU usage. But open the main window, and back up to between 100% and 130%.

Screen Shot 2018-01-04 at 15.37.23.png

This is still happening with the latest build (152).

Build 150 fixed it for me. 152 also still good on my side.

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)

Architecture:    x86_64

Report Version:  19

 

Command:         Sourcetree

Path:            /Applications/SourceTree.app/Contents/MacOS/Sourcetree

Version:         2.7 (152)

Parent:          launchd [1]

PID:             6935

 

Event:           wakeups

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

Duration:        6.40s

Steps:           3

 

Hardware model:  MacBookPro11,5

Active cpus:     8

 

Fan speed:       3539 rpm

 

 

Powerstats for:  Sourcetree [6935]

UUID:            BDA3F21B-4C84-312A-93C9-F5FAD260A32E

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>

 

  Binary Images:

         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

Still happening to me in build 152 after upgrading from mac OS Sierra to High Sierra.

I spoke too soon. 152 still has this problem.

Hi @Brian Ganninger 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.

Now that we've wrapped up 2.7 and 2.7.1 we're able to dedicate the next release focused solely on performance and reliability across the board.

Thanks for the update - I look forward to the upcoming releases.

V 158 still with the issue

@Brian Ganninger:

I noticed that the issue that appears to be tracking this problem (or at least a similar one) is prioritized as "low": 

https://jira.atlassian.com/browse/SRCTREE-5306

An issue closed as a duplicate was marked as "highest":

https://jira.atlassian.com/browse/SRCTREE-5318

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?

The tickets are a bit out of sync… the morale of the story is we're currently working on it for the next update.

Still happening on 2.7.2 (168) - Is anyone really working on this? The program (as nice as it may be) as such is barely usable right now.

Hi @Brian Ganninger - 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:

  • Closing all windows, and reopening the app with only the Repository Browser window open leads to normal, very low CPU usage
  • Working within a very tiny repository (i.e. 2 commits, 8 files) CPU usage will peak briefly/periodically around 10-15% and then drop to very low usage.
  • Working within a very large repository (i.e. hundreds of commits, thousands of files) CPU generally usage stays at 100%
    • Opening this window initially, not clicking on anything, and switching immediately to the Mac Activity Monitor, the CPU actually hovers around 50% for around a minute, then drops to very low usage.
    • Clicking back to this window and then back to Activity Monitor immediately SourceTree jumps to 100% CPU for 1-2 minutes, then drops to very low usage. Periodically spiking to 100% again even while in the background.
    • Once I start navigating around between views (File Status, History, various branches), it never seems to drop back below 100% usage, even if I focus on another application for a while. I suspect this is where most of the other users' reports are coming from, as it's pretty normal usage. It simply appears to be always at 100% usage.
    • Once the 100% CPU has started, closing the large repository's window, so that only the Repository Browser is open, does not stop the CPU load for a couple minutes. But once it does stop, it seems to act closer to when the app was launched with just the Repository Browser, but hovering periodically around 75% usage. This leads me to believe this is possibly a leaky object reference tied to a long-running refresh or redraw operation.

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?

Thanks.

This is still an issue.

21 june, still 110 - 150% of CPU loading. Macbook always using fan, always hot, thanks for your soft. WTF? 

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 @Brian Ganninger, 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%.

This widget could not be displayed.

Also noticed about high CPU usage. To fix this temporary need restart sourcetree.

Process `/usr/libexec/nsurlstoraged` taking too many cpu time, after that Source tree may crash.

This widget could not be displayed.

I have the same problem. Over 100% CPU Time. I have to Kill the Process all the time. Version 2.7 (152). MAC OS X El Capital 2.5 GHz Intel Core i7, 16GB DDR3

This widget could not be displayed.

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 :-(

This widget could not be displayed.

I think I'll bail on SourceTree until this gets resolved. It's killing my laptop battery life. Ping me if it gets fixed. 

This widget could not be displayed.

Same here! CPU is killing it. When on battery it drains new macbook in an hour. Even with just one repo open.

This widget could not be displayed.

Yeah also seeing this - please fix 

This widget could not be displayed.

 I am also experiencing this and cannot figure out how to fix it. Cannot use ST because CPU runs at 90-100% and never goes bellow. On paid bitbucket account too. 

This widget could not be displayed.

Well, I simply can’t afford to use Sourcetree in this state. So after about 5 years of happiness, it’s Good bye Sourcetree, hello Tower.

This widget could not be displayed.

i'm also giving up on this unusable version of sourcetree

This widget could not be displayed.

Same issue - SourceTree Version 2.7 152, High Sierra 10.13.2.  Cpu above 100% routinely.  I typically have 2-3 SourceTree windows open - but closing the "extras" and getting down to 1 window doesn't change the cpu consumption.  

Per poster above - downgrading to 2.6.3 (134) works great.

I really start wondering if they mine bitcoins in background... Version 152, still present, almost never going below 100%, raising as far as 270%, putting my machine on its knees...

Still the same situation with the new 2.7.1 (159)...

This widget could not be displayed.

I have the same issue on my Mac OS X El Capitan / 10.11.4, with SourceTree 2.7(152). I've downgraded to 2.6.3(134) and the cpu usage drops back down. 

This widget could not be displayed.

Me too! It gets to the point that I'm looking for alternative.... Tired of high CPU.

Thanks for doing nothing about it.

This widget could not be displayed.

Same issue, CPU > 100% most of the time the program is running. 

This widget could not be displayed.

Same issue for me with build #159. 113% CPU usage with only main window opened in SourceTree.

This widget could not be displayed.

I got sick of waiting & switched to GitKraken.

This widget could not be displayed.

Experiencing extreme slowness along with the high CPU usage, switched to GitKraken. Sucks, I like SourceTree better, but it's literally unusable.

I switched back to 2.6.3 and it works perfectly. I even like it more as the commit list is more compact (less line height) so more history is viewable on the screen at the same time. Deactivated the auto-update.

This widget could not be displayed.

It'd be great if Atlassian could provide an update to this issue. 

I prodded them on Twitter: response was "Regarding the high CPU usage, our team is aware of the issue and continuing to investigate solutions. Thanks for reaching out!" (as of March 12th). 

That doesn't convince me they're active on this. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published May 30, 2018 in Sourcetree

Tip from the team: configuring Git or Mercurial in Sourcetree

Supported Platforms macOS Windows To make using Sourcetree as simple yet powerful as possible we embed (bundle) dependencies such as Git, Git LFS, and Mercurial. We strive to keep these...

860 views 2 3
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you