SourceTree stalls severely when computing diffs on minified JavaScript files

[farmerpaul]

Our various git repositories contain minified JavaScript code here and there (long one-liners), and when this code changes and is regenerated by our compiler, SourceTree often has a really hard time displaying the diff. Most of these minified files are between 60KB and 170KB in size, and if I happen click one of those files in the file list by accident (it's always an accident – I'm never actually interested in viewing the diffs of minified compiled code), SourceTree then freezes for about 1-2 minutes and gives me the spinning beachball. My CPU usage goes through the roof during that time. I can't do anything in the app – can't cancel the diff, can't browse any of the other repositories. I just have to force it to quit or wait until it's finished processing.

It's really starting to affect my productivity negatively. I have to be very careful about which files I click in the list of modified files. Sometimes it's unavoidable, however, because if I click a commit for which a minified JS file is the first file in the list of changed files, SourceTree generates the diff automatically, and I'm stuck again for 1-2 minutes.

As a temporary workaround until SourceTree's diff algorithm for long one-liners is smarter and more performant, is there a way to prevent SourceTree from trying to diff particular files in my respository? I wish I could add these files to .gitignore, but unfortunately our project environment requires these files be tracked and versioned in the repo.

Cheers.

[farmerpaul · Accepted solution]

For those interested, this appears to be a valid bug (a rendering bug) and it is being tracked in JIRA here: https://jira.atlassian.com/browse/SRCTREE-2183

[KieranA]

Hey farmerpaul,

Just as a note on this, SourceTree doesn't have a diff algorithm. We call an external process to Git asking for the diff with the diff options as specified by the user on that particular file and just read in the output generated by Git. This is done on a background thread which is why you'll see the spinner in the diff panel in SourceTree, it shouldn't be causing SourceTree to stall.

One thing you could do is to provide us with output from Console when this stall has happened to see what's going on. As I say though, SourceTree's designed to continue working regardless of the diff size as many of us have very large diffs which take Git a while to return back from.

Cheers

[farmerpaul]

Hi Kieran,

Thanks for that explanation. Then it's certainly curious that ST is beachballing whenever I diff any of these files, given that it's performing the diff in a background thread.

I'm happy to provide more info. I'm not sure if this is what you're talking about, but here's what I could find that seemed relevant in Console's system log:

2014-03-17 12:38:21.163 PM WindowServer[112]: disable_update_timeout: UI updates were forcibly disabled by application "SourceTree" for over 1.00 seconds. Server has re-enabled them.
2014-03-17 12:38:35.163 PM WindowServer[112]: 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.
...
2014-03-17 12:39:38.724 PM WindowServer[112]: common_reenable_update: UI updates were finally reenabled by application "SourceTree" after 78.56 seconds (server forcibly re-enabled them after 1.00 seconds)

Does that help, or were you looking for something else?

[farmerpaul]

Just another comment, which may be relevant to you:

Some of our minified files have comment blocks at the top of the files (< 80 character lines separated by newlines), and the minified code is found in one long line at the very end of the file. I have noticed that when clicking these files, if my window is small enough that only the comment block appears in the diff view, the beachballing doesn't occur right away. The diff appear immediately. It's only when I scroll down to the bottom of the file, where that long line of code is, that SourceTree then freezes.

This makes me think that it's not the actual diff algorithm that's taking a while, it's the way ST tries to render the diff returned by git that may be causing ST to freeze. Just a thought.

[farmerpaul]

Hi Kieran – are any of the above details useful to you? Can you confirm it's a bug with the rendering of diffs?

[KieranA]

Hey,

I'd need a reproduction case, otherwise I'll just be guessing the multitude of problems it could be. If you can come up with a repro and add changes to a file which would cause SourceTree to beachball then we can test that and move on from there.

Cheers

[farmerpaul]

Yup, no problem at all, Kieran. Sorry, I should have thought of that. Here's your repository:

Test repository on GitHub

There's only one file, calendar.js, which if you open the master branch in SourceTree and click that file, SourceTree stalls for a good couple minutes.

I'm not sure if it has anything to do with my diff settings, but I have 6 lines of context, and I have Ignore Whitespace enabled.

This issue is totally bogging down the app for me every day now... 2 minutes here, 4 minutes there. Requires some clever changes to my workflow so that I've got other things to stay busy with while SourceTree does its thing!

[farmerpaul]

Hey Kieran,

Any luck reproducing the bug with that repro?

If it's of any further help, my Mac is a 13-inch mid-2009 MacBook Pro, 2.26 GHz Intel Core 2 Duo. I typically wait between what feels like 1 and 3 minutes for SourceTree to display the diff for that one file. Since my Mac is a few years old yours might perform much better, but I hope you can still notice the delay.

[KieranA]

Hey,

It was slow on my mid-2012 MBP-RD so I'm assuming it's a rendering issue rather than a diff issue. I've created an issue for you here: SRCTREE-2183 - Diff rendering slowness

Sorry for lack of response, us developers don't really use AAC due to demand, but we use JIRA so if you want to follow that issue or comment on it you'll likely get a response soon :)

Cheers

[farmerpaul]

Thanks Kieran, glad to know I'm not nuts!