How can I troubleshoot Sourcetree slowness?

[Daniel Serodio]

Almost everytime I use "Pull" or "Push" from a Git repo, Sourcetree takes a long time, even when the changes are small.

I know this isn't enough information for a useful bug report. How can I help troubleshoot this problem?

[stevestreeting]

OS X I/O is usually really, really solid, which is why I'm surprised you're seeing this, I certainly haven't encountered it before (I test on a 2007 MBP too and it doesn't demonstrate this issue).

You can use 'sudo fs_usage' to monitor disk I/O and you can add processes parameters to filter it. In this case, SourceTree isn't technically waiting on file I/O, just inter-process I/O, but maybe there will be something there that gives a clue anyway, since the OS uses the same pool of 'file' handles in either case.

[Daniel Serodio]

Thanks for the detailed explanation. The workaround you suggested does sound like it could make matters worse.

AFAIK I'm not running anything that could be stressing I/O (even thou I usually have lots on open apps), but I'll try to keep an eye on I/O when I see the beachball in ST.

It's a shame that iotop on OS X is so flaky, do you have any suggestions to monitor I/O usage by process?

[stevestreeting]

Thanks, this basically nails down exactly what was happening. SourceTree is responding to a notification from FoundationKit which is saying "there's more output available from the git task". This is because SourceTree basically fires off the push then asks the OS to tell it when there's more data to display - it does this precisely to avoid spinning taking up resources, not blocking and so not creating a beachball scenario.

However what's happened here is that FoundationKit has subsequently sent SourceTree the 'more output is available' notification, but when SourceTree asks for that output, it hasn't responded quick enough to avoid the beachball. This is not SourceTree waiting on output when it shouldn't, because it's only asked for it when specifically told there's more to read right now. The OS is just not delivering on its promise of the available output quickly enough. I've never seen this happen before even on old machines.

I basically have no way to avoid this except perhaps to put in a timeout / retry loop in the place where I respond to the OS notification. All this would do though is keep the beach ball from appearing (it wouldn't actually make the process go any faster, since ST can only proceed when the OS gives it the output it claimed was ready), and it might actually make things worse, since if I/O bottlenecks are the problem then ST may keep joining the back of the queue on retry.

The only reason I can imagine that this would happen is that your machine is extremely I/O constrained, to the point where the ability of the OS to service requests for I/O are not keeping up with the events that are raised to say I/O is ready. Do you have anything running on your machine that could be stressing I/O in particular?

[Daniel Serodio]

I just got the beachball after a push, right after "updating local tracking ref 'refs/remotes/origin/master'" (and before the "Completed successfully"). I managed to capture the output of Activity Monitor's Sample Process: Sample of SourceTree.txt

[stevestreeting]

I'm clutching at straws now because I just can't reproduce this behaviour, but have you tried using the system git in SourceTree instead? Just incase something about the repo is semi-dependent on the newer version you have from homebrew or something.

[Daniel Serodio]

Sorry for not checking before, I assumed SourceTree would use the same Git I use from the shell by default, but I didn't change this setting from its default so it's already using the embedded Git.

[stevestreeting]

If you're using that homebrew Git install in SourceTree (Preferences > Git), does resetting to the embedded Git in SourceTree make any difference?

[Daniel Serodio]

The machine is a mid 2010 Macbook (2.4 GHz Core 2 Duo) upped to 8 GB RAM.

I don't use Macports, but I'm using Git 1.8.0 from Homebrew. SSH is OS X standard.

Pulling/pushing to Bitbucket is somewhat slow - I've just cloned another copy of this repo to get this info:

$ time git clone git@bitbucket.org:internetgroup/vulcano.git
Cloning into 'vulcano'...
remote: Counting objects: 7256, done.
remote: Compressing objects: 100% (4395/4395), done.
remote: Total 7256 (delta 2222), reused 3135 (delta 820)
Receiving objects: 100% (7256/7256), 26.21 MiB | 285 KiB/s, done.
Resolving deltas: 100% (2222/2222), done.
git clone git@bitbucket.org:internetgroup/vulcano.git  1,09s user 0,48s system 1% cpu 2:07,98 total

[stevestreeting]

I've been doing some testing here and I can't reproduce this on 10.7.5 or 10.8.2, using Bitbucket as a remote and authenticating git via SSH keys. In all cases the push / pull behaves as expected and I never see a beach ball. My 10.8.2 machine is basically a fresh install so I had to set up my keys etc but it worked flawlessly.

My test machine is a 2010 i5 MacBook Pro with a non-SSD hard drive, fairly modest configuration so I don't think it's atypical.

Is there anything else that might be unusual about your machine or the repo? As in machine specs, whether you're using macports or something else which might have installed a custom SSH, particularly huge repo etc?

[Daniel Serodio]

I already used SourceTree in Lion, but mostly with Github and not Bitbucket (maybe the beachball is related to some network issue).

I'm pretty positive the slowness already existed in Lion but I may be wrong.

[stevestreeting]

This is actually the simplest of all options then since all the authentication will be handled internally by SSH, without any interference by SourceTree. Therefore once 'git pull' has been called, all the processing is entirely confined to git and ssh, with SourceTree just waiting for output / completion events in the background, so the beachball is very puzzling.

Apple did change the version of OpenSSH in Mountain Lion, can you recall whether this issue appeared when you upgraded from Lion, if you used SourceTree across the upgrade? I haven't seen this issue myself in testing, but I only have 10.8 on a test boot right now due to a bug in which caused builds signed on 10.8 to have keychain issues on certain OS versions.

[Daniel Serodio]

I use SSH keys

[stevestreeting]

Just a quick follow-up; do you use SSH keys or manual user/password verification?

[Daniel Serodio]

1. OS X 10.8.2
2. The remote URL is SSH from Bitbucket
3. No
4. Yes

I'll use Sample Process ASAP

[stevestreeting]

It should just be waiting for the pull here and not actually doing anything in the main thread that would cause the beachball, I can't reproduce this here. Can you confirm:

1. your full OS X version including bugfix number ie 10.8.x, 10.7.x
2. the kind of remote URL you're pulling from (HTTPS, SSH)
3. whether you're going through a proxy
4. whether the pull eventually completes successfully

If you have the opportunity, if you Can open Activity Monitor and use the Sample Process on SourceTree while the beachball is present that might help. Thanks

[Daniel Serodio]

I've just pulled with the "rebase" option checked, and the beachball appeared after it ran "git -c diff.mnemonicprefix=false -c core.quotepath=false fetch origin"

[stevestreeting]

Hmm, that's one I haven't seen before, the beach ball shouldn't happen because the real pull is done in the background. Perhaps it's some follow-up process that's usually very fast but isn't in this case.

If you go into Preferences and check the box 'Always show full output', then this dialog will show more detail of all git processes (and require you to manually close it on completion instead of it happening automatically), so this might give us more information about where exactly this is happening. Please can you try this and let me know what it shows, ie when the beachball happens in relation to this more detailed dialog and the contents of the output?

[Daniel Serodio]

When it's showing the "Pulling Branch master From origin" dialog. The progressbar animation stops and the "spinning beachball" appears.

[stevestreeting]

Which part feels slow?

1. The time it takes for the pull/push dialogs to display their final content
2. The actual pull/push process itself after you confirmed the dialog
3. The refresh afterwards?