Source Tree on Mac is very slow to respond

[David Jameson]

I've seen this issue over time as Source Tree has evolved, it's not a new issue. At some point, it becomes very slow to respond. If I try to stage some files, there will be a long delay (can go into minutes) before SourceTree will actually stage the files and in the meantime you see the standard Mac spinning beachball and you see some animated circular icon in SourceTree as well. It gets to the point where clicking on anything just initiates a delay.

Last night, it took at least 5 minutes for me to stage a few files, commit them and then push them out, the delays being due to SourceTree being unresponsive.

This is happening with Mac version 2.0.2

Any ideas?

I appreciate very much that this product is free, I would have been happy to pay for it, it's damn good, but it needs to be solid/responsive all the time.

[David Jameson]

Yes, I know exactly what's wrong but I've kinda given up reporting it  (the price one pays for something that is free I suppose)

In my case, I am saving JSON files created from MaxMSP. Turns out that even if you make just a minor change at the visual end, the JSON that is produced may have the objects in different orders and so although the JSON is semantically almost identical, syntaxwise, text can have moved around drastically (e.g. stuff near the top in one version may be down near the end in another version).

Turns out that in the latest version of Max, they've applied some kind of sort ordering so that JSON files get saved essentially the same way every time and so the differences are now tiny. Consequently, SourceTree works beautifully again.

As I said a year or two ago, there needs to be a way to turn off that diff process completely in SourceTree.

[Marco Schirrmeister]

I see similar things. Even with latest ST version (2.0.5.5). The app is not responding and the spinning beach ball shows up when there many changes for example in a 900kb file.

Looks to me like that SourceTree has problems with the diff for larger files with many changes. Almost unusable this tool.

[David Jameson]

I'm sad to say that 9 months later, I'm still seeing this issue. However, this time, the problem did not happen with some exotic code base but with some simple Java source files. Typically once this happens, CPU utilization hovers anywhere from 90% to 101[sic]%

This time around however, because I was running Activity Monitor, I took a sample and it's not too hard to see where it's getting stuck. However, the file has over 2000 lines in it so I'm not sure you really want me inserting that text here. Let me know where I might send it.

Force-quiting and restarting causes everything to work fine again immediately.

screenshot_295.png

[David Jameson]

No, but I've tried it from other GUI products like Tower and had no problems. This "feels" like a GUI management problem, not a problem getting at the underlying data in the respository.

[Seth]

Just for comparison, have you tried the same operations from the terminal?