Listing of revisions is very slow

[Andrew]

Hi Steve,

On the old support forum a couple of weeks ago you commented on a post with the same title as this post saying this issue would be fixed in the next release and it was related to Lion. I have updated to the latest release 1.2.90 via the App Store and it hasn't made any difference at all.

I'm posting here as the old forum appears to have now been removed, however you can still see this page in Google's cache:

http://webcache.googleusercontent.com/search?q=cache:7Vq6yDwet4wJ:support.sourcetreeapp.com/discussions/problems/490-listing-of-revisions-is-very-slow+sourcetree+slow+lion&cd=1&hl=en&ct=clnk&gl=uk

Any other ideas on how to fix this? It makes the app pretty much unuseable.

Thanks.

Kind regards,

Andrew.

[Andrew · Accepted solution]

Hi Steve,

The latest beta, 1.3b3, has solved this issue and the listing are now super quick. Excellent work, thanks very much.

Kind regards,

Andrew.

[stevestreeting]

Awesome, I was hoping it would! Thanks for letting me know.

[Andrew]

Hi Steve,

I've not used SourceTree in about 6 months and last time I used it everything was fine, I have just started using it again in the last couple of days, on the latest version (1.5.7.1) and it is slower than ever to the point of almost unusable. I'm on the latest version of OS X, 10.8.2, on a MacBook Pro with 8Gb RAM and an SSD and plenty of free disk space. I've used the same repository with TortoriseHg on Windows and have no problems at all, super quick. Any ideas?

Kind regards,

Andrew.

[Paul Hoepfner-Homme]

I am using SourceTree 1.4.4.2 on OS X Lion 10.7.4, and boy does it ever operate sluggishly sometimes! I notice similar behaviour with Tower, and even GitHub for Mac, but it's the worst in SourceTree. When it's doing whatever git operations it has to in the background (refreshing the log, pulling data from the remote), it bogs my MBP down to a point where I can barely do anything. My wireless trackpad becomes almost fully unresponsive - the cursor is just jerking around.

No other piece of software besides SourceTree and Tower (and to a very limited extent, GitHub for Mac) causes this high-priority CPU drain that actually interferes with the processing of my wireless trackpad's cursor movement. What is it about git that requires that all other processes on my OS wait for its operations to be complete? It's insane. I love git, but this is a little bit insane! Awful, awful UX.

[stevestreeting]

Git is actually very fast when you compare it to other version control systems so I'm surprised you have this problem. I've added some extra optimisations in SourceTree 1.5 which is in beta right now (http://blog.sourcetreeapp.com/2012/07/06/sourcetree-1-5-beta-1/) but mostly that's about throttling lots of parallel processes on slower machines - if you think it's down to a single git command then it probably won't help.

In order to slow the machine down to the extent that devices start misbehaving, your machine must already be heavily loaded. A single git command won't usually occupy more than one core, and memory usually sits at a manageable level - are you 'sailing close to the wind' in terms of resources? I have a 2-year old mid-range MacBook Pro on which I'm constantly running XCode, Chrome, iTunes etc in addition to SourceTree, and I never see this level of resource deprivation.

[Paul Hoepfner-Homme]

Hey Steve. Yes, I know, I too have enjoyed using Git on the command line for its speed - much faster than SVN ever was. I've never had any problems with 100% CPU drain when using it from the command line. It's just these git GUIs that exhibit this curious behaviour.

I don't feel I'm sailing close to the wind at all, actually. My system performs great otherwise, even though it is a mid-2009 MBP (I upgraded it with an SSD, which feels great). I too always have a ton of programs open - Chrome with dozens of tabs, iTunes, SublimeText, Terminals, Mail, Transmit, MAMP, etc. Just looking at my free RAM... looks like I've got about 1 GB inactive. I never encounter swap thrashing these days, either.

It's just these git GUIs that cause my system to freeze in this way, and so far SourceTree is the worst, especially when it refreshes the logs after I haven't visited the application in a while - I sometimes am waiting 20 or more seconds. I've contacted the Tower folks about the same issue and they say other customers have encountered this problem and they're working on a solution. So I know I'm not the only one.

I will try the 1.5 beta - thanks a bunch!

[Paul Hoepfner-Homme]

Hey Steve - just wanted to mention that the 1.5 beta is performing way better so far. I've only used it for a bit but I have yet to experience the same cursor jerkiness & CPU drain. Fingers crossed! I'll post another update when I'm more certain.

[stevestreeting]

Great, thanks for letting me know. It's an odd one this in terms of reproducibility, but the 1.5 changes did seem to make things more predictable. The issue (and it was initially reported by someone on a quite highly loaded 1st-gen MacBook Air) seems to have been down to GCD thinking that when you call out to git, that counts as as a wait state on File I/O so if there's anything else in the queue it will fire up another thread while it waits for that File I/O. But of course, git itself is using CPU too, it's not just a file operation, so it seems GCD makes bad scaling judgements when you call out to external processes like this. In 1.5 I'm doing my own throttling instead of leaving it entirely to GCD and that seems to have helped.

[Paul Hoepfner-Homme]

Hi Steve,

Just mentioning that I haven't been able to reproduce this issue whatsoever since trying out 1.5 beta. Thanks and great work!

[stevestreeting]

Excellent, thanks for updating me, I'm glad that 1.5 is working out for you.

[VSquash]

I'm using 1.3.0.b3 on MacOS 10.6.8.

I noticed that sometimes software works extremely slow when mergin branches. I opened Activity Monitor, and I saw huge amount of Python processes and CPU load 100%. I'm not sure my screen can help, but maybe. Also I use Russian user interface, but all important information you will see anyway.

http://img210.imageshack.us/img210/1180/cpuloading.jpg

[stevestreeting]

All SourceTree does is call 'hg merge'. If Python goes crazy, I wonder if there's something particularly unusual about this merge? I've done quite a lot of hg merges (SourceTree and Ogre) without seeing this. You could try it on the command line to compare.

[Barry Weinstein]

On beta 3 and Lion.

When I first start up Sourcetree it is fast. It seems to degrade over time independent of other software running on my machine. So it's hard for me to get a clear measure of speed.

I develop in Eclipse using GWT and hitting a database in a Parallels VM. Once I start this combination up Sourcetree slows quite a bit more. I do have 8 gig of RAM. I have 86 gig out of 320 gig available on my hard disk. Also the CPU consumption of these processes is typically very low <4% each.

To quantify the speed differences...

Fresh login with unloaded machine - render the changelist tree of a 1250 changelist repository - between 2 to 3 seconds.

Once Eclipse and Parallels come into the picture it regularly drops to over 5 seconds.

[stevestreeting]

Anything of note in Activity Monitor when it comes to free memory and disk activity? VMs tend to be very hungry is all I'm thinking.

For reference, when I start SourceTree here the first display is very much dependent on what else is accessing memory at the same time. Even if I'm quite heavily loaded, if I'm not thrashing elsewhere my initial refresh time on the SourceTree repo (Mercurial, 2200+ revisions) is 1.5s (1s to refresh after that). My typical setup is XCode 4.2 loaded, iTunes, 1-2 copies of SourceTree loaded, Mail, Chrome and a few social apps - XCode and Chrome being the 2 biggest hitters. I do see more slowness if I've been starting other large programs recently - but this really isn't anything to do with SourceTree.

Bear in mind that in order to perform most of its actions, SourceTree has to launch short-lived extra processes (git and mercurial mainly) - 90% of the delays under load are caused by this, because starting a new process is something that OS X has to schedule, so it's susceptible to more load variation than just executing the SourceTree code that's already in memory. Unfortunately there's not a great deal I can do about that. I heavily parallelise and cache data as much as I can, but it does eventually become a critical path.

[Peter Paul Ex Machina]

Have you increased the amount of those short-lived processes from v1.2.8 to v1.2.9?

Did not notice anything extraordinary in Activity Monitor (v1.3b3 did use less memory though (25MB vs 30MB or so)).

[stevestreeting]

"Have you increased the amount of those short-lived processes from v1.2.8 to v1.2.9?"

No, not at all. Only very minor bug fixes were made between those 2 versions. The only significant difference was that 1.2.9 was built with XCode 4.2 & llvm rather than XCode 3.2 and gcc, which unfortunately was not something I could put off any longer. These builds do seem to run faster on Lion than Snow Leopard (it was the reverse before), but the other optimisations I made in the 1.3 betas outweighed that on my 10.6 / Core 2 Duo test machine. However, that's got 4GB (was upgraded from the factory default some years ago)

[Barry Weinstein]

Hi Steve,

I took a look in Activity Monitor as you suggested. I saw two things potentially interesting.

I run Dropbox. Occasionally when I work with Sourcetree I see Dropbox sync kick off. One of the files being uploaded is sourcetreeconfig. I can't remember the exact spelling since I can't see to get it to happen again. However, Dropbox is a dog on my machine and the CPU load goes way up when that happens. I saw this happen a frequently when I began my experimentation.

I also saw a gazillion Pythons kick off as expected. One time a Python process was left consuming a lot of resources. It stayed even after exiting Sourcetree. I had to kill it manually. I can't imagine this happens a lot since my fan would have regularly idled up. However I've been playing with Sourcetree a lot just now so that might have caused it.

I also run a mercurial plugin in Eclipse. It's active in my current workspace. Perhaps that affected my results. However I've seen the usual slowdowns in a non-mercurial workspace.

[stevestreeting]

I run Dropbox too, but I don't put any of my repositories in it - if it's uploading sourcetreeconfig, that suggests you're keeping a repo in there and I suspect that might have an impact. It might even generate extra file events causing SourceTree to refresh more often.

[Barry Weinstein]

I did a two day experiment. I moved my repositories out of the Dropbox folder on the first day. I can confirm that there was never any Dropbox activity during my development or use of Sourcetree. This did not help Sourcetree. By the end of a 10 hour day of constant work Sourcetree was just crawling. 8 second refreshes were typical. It degraded during the course of the day.

The second day I did not start Parallels 7 at all. My code was still out of Dropbox. Sourcetree was fine all day. This is the first time in a very long time that Sourcetree was fine all day. It's also the first time in a very long time that i didn't run my Parallels VM. I came to expect 2 seconds refreshes from Sourcetree and got them consistently. Exceptions were refreshes after a commit. They were around 4 seconds.

Parallels does not consume much CPU. Activity Monitor shows it hovering at 3%. It is not the only process at that level. I don't see any degradation in other software that I run when using Parallels (around 10 applications). I also disconnected shared mount points I found between the two machines.

With fingers pointing to Parallels I'm not sure of my choices. I have to run that VM if I don't want to always travel with two laptops. It seems that tuning of Sourcetree and worrying about CPU loads are not going to help. Is there any chance there is just some contention on a resource which is causing the delay?

People who have had Sourcetree performance issues all differ in details (versions, speeds, OS). Could it just be a question about what other software they are running and how it competes with Sourcetree for some particular resources?

[stevestreeting]

When you're running Parallels, how much memory do you end up having free? I run VMWare Fusion sometimes, and it was always a bit of a struggle until I upgraded to 8GB. It was memory far more than CPU that caused the issues for me (although it was with all apps really).

As I've mentioned before, a particular issue for SourceTree is that calling git/hg launches a new process, which can be more contentious if there are scarce resources than simply 'waking up' an existing process. OS X is pretty good at making launching a process fast if you've previously launched it, because when the process stops it doesn't actually unload it as such - it parks the memory in 'Inactive' and if the same process is launched again it just resurrects it without touching the disk. However if memory is under pressure, it will have to reload the binary again from disk which is much slower. Disk speed is important too because obviously git and hg access the disk to do almost all their work (and I've stressed before the importance of having more than 10% disk space free, OS X likes it that way because of its automatic defrag behaviour), but RAM is probably the first hurdle. CPU isn't really stressed that much by SourceTree.

You should also try the 1.3 beta if you haven't already, I assume you're still using 1.2 given the refresh times you're talking about. 2-4 seconds was common on 1.2 with Mercurial, it's generally now around a second with 1.3 in my experience, except sometimes when load from other apps is higher or at first startup if other things are going on. It's worth saying all the speed improvements I've achieved are simply from avoiding calling git/hg as much, or by parallelising multiple calls to them when I need multiple bits of information, rather than doing them in serial. Just launching these processes and waiting for them is 80+% of the time that SourceTree spends doing things.

[Barry Weinstein]

Hi Steve,

I always wish I could give you good news :-)

I'm running 1.3.0b3. I do have 8GB of RAM.

I've allocated 3GB of RAM to my VM. With Parallels running and looking in the System Memory tab of Activity Monitor shows:

Free 2.14 GB

Wired 3.96 GB

Active 1.38 GB

Inactive 526.1 MB

Used 5.86 GB

Regards,

Barry

[stevestreeting]

Damn, not RAM then. I run XCode and various other things most of the day and my memory usage is about the same as yours, but 1.3 is really quick. I wonder if it's the disk usage of Parallels then? Is there much disk activity going on in Activity Monitor?

[Peter Paul Ex Machina]

As a side note to RAM. I have noted that OS X sometimes seemed to get sluggish when you passed the point of 75% usage of your RAM, both with 2GB and with 4GB of RAM. I suspect OS X might start swapping memory at that point. Perhaps it acts similarly when you 'only' have 2GB out of 8GB free?

If that's the case and cause then you should see load spikes due to swap IO's though I think...

[Barry Weinstein]

That's an interesting point Peter. I took a look at my swapping. Today I see a total of 500 MB of page outs. That's a lot of swapping.

One slow refresh in Sourcetree caused 25 MB worth of page outs. While I kept Sourcetree running I started some other programs and had continual swapping. I shut down Sourcetree and the swapping seemed to stop even when launching a kind of heavy program. My sample size is too small to draw any conclusions.

I'd like to keep my eye on memory evolution over the course of the day tomorrow and see if I can detect a pattern. I'll report back.

[Barry Weinstein]

Sorry it took so long to follow up. At about 1.5 Gig remaining I start to see swapping. This is consistent with Peter's observation. If I am diligent to keep my memory consumption below that by closing programs Sourcetree's response times are consistent and tolerable. Displaying the tree takes about 2 seconds. The final work to show the pending files on the bottom left and a diff on the bottom right consume another 3 seconds. It's that initial 2 second response that makes the whole display tolerable.

[Barry Weinstein]

My final comment on this topic. And there's no need to reply. I just didn't want to leave this thread with incorrect information from me.

I had the worst time yesterday with speeds in SourceTree. I had 2.5GB ram free (free + inactive) and there was no swapping for the entire day. Whenever I used sourcetree the fan would start to idle up. No other program causes this so quickly. No other program consumed more than 2% CPU at the time.

At this point I am concluding my 3 year old MacBook Pro is just too old. SourceTree seems clearly CPU bound on my machine. 2.93 GHz Intel Core 2 Duo. 8 GB ram. For me..Case closed.

[Peter Paul Ex Machina]

Final comment from me as well then I guess.

First of all, thanks for all the effort that was put into this both by the developers and by bweinste!

I really wish that performance could still somehow be improved. I love the UI of SourceTree, but the difference in performance with alternatives such as MacHg is orders of magnitude. The bottom line is that for every day use by professionals speed is one of the most important features of software, so this deserves even more attention then it seems to be getting now.

I hope I'll still see some improvements in SourceTree, but I won't hold my breath and will remain on the lookout for a worthy alternative.

Needing to upgrade hardware (or OS X) is not a reasonable solution for this kind of software!

[stevestreeting]

I'm sorry this isn't solved for you. I put a lot of optimisation effort into 1.3, and have received lots of reports that it's very snappy, even on very large repositories.

For the record, my developer machine is a 2-year old mid-range MBP (i5) with 8GB. I also test on a 2007 MacBook Pro running Snow Leopard, and I can definitely attest that since the switch to XCode 4 / llvm / 10.7 SDK, builds run slower on 10.6 than on 10.7. However, the reverse was true when building on XCode 3.x, and at this stage, judging by web traffic, the numbers are now in Lion's favour by a fair margin (plus XCode 4 is now basically mandatory), and of course Mountain Lion will be out in the summer. Even so, I wouldn't say it's even close to unusable on that old machine, just a bit slower when compared with my 2010 machine running 10.7.

I'll obviously keep things under review anyway.

[Barry Weinstein]

I genuinely hadn't realized that there was someone else still suffering with this problem. Since seeing Peter's post I decided to take it up again. After all the review of CPU, available RAM, and available disk space nothing had helped. On a lark I decided to look at Python itself. That seems to have been my problem.

I hadn't realized that Sourcetree was using the platform's installation of Mercurial and Python. In fact, I never gave it much thought. When I started looking at that it certainly was. So I updated my Mercurial to the latest. Then I noticed during the install of Mercurial it indicated that Python 2.7 was required. The installer puts the extensions into the 2.7 site-packages.

So I altered my python binary to the stock Apple 2.7. I used the stock Apply python binary and modified com.apple.versioner.python.plist to point to 2.7. Now SourceTree behaves perfectly. It's actually quite snappy.

I've had only three days of development since the fix. So far so good. I usually wait longer to report my situation so that I see it's stable. But I decided to report my situation sooner since others are also having the problem.

I'm kind of pissed at myself for not looking into this before.

But I'm happy that I was finally able to give good news. :-)

Peter, I hope this offers you a clue to your problems as well.

Barry

[Barry Weinstein]

Well I solved it for me. Peter's post prodded me to look into it further. I intalled the lastest Mercurial and cleaned up my Python install. Mercurial installs into 2.7 site-packages. So I grabbed the custom Apple python binary from my son's computer. I had lost that over time through various OS updates. That was stupid of me to alter /usr/bin. I then modified the setting in ~/Library/Preferences/com.apple.versioner.python.plist to point to 2.7.

Now I get very good performance. Also, the fan does not idle up while using SourceTree. I hope this helps someone else.

Steve, I'm finally able to give you good news. :-)

[Barry Weinstein]

Sorry for the double post. I didn't see my original one because of my setting for viewing comments.

[Peter Paul Ex Machina]

Unfortunately v1.2.8.1 is still a lot faster then v1.3b3 for me, so I've downgraded untill you resolve this issue.

This kind of slowness almost makes me reconsider just using the command line. As an old paying customer I hope this will be fixed as soon as possible.

PS: I'm using OS X v10.6.8 (Snow Leopard)

[stevestreeting]

I'm getting totally contradictory information on this - 1.3b3 is vastly faster than 1.2 for me, and for the original poster (who has now marked this as answered). I've tested on 10.6 as well as 10.7 here and I see the same speed-up. 1.3b3 includes a huge number of improvements, especially in parallelisation, that it's bizarre to me that 1.2.8 could be faster. There's really nothing else that I can think of to 'fix' here. The drop in performance from 1.2.8 to 1.2.9 appears to be down to the new compiler in XCode 4.2, which definitely favours 10.7 now, but even so the 1.3b3 changes more than compensated for this in my 10.6 tests.

[Peter Paul Ex Machina]

I understand this is a difficult to reproduce and thus fix issue. Let me give you some more info to work with:

• I am currently using a 13" 2GHz Core 2 Duo MacBook Pro
• I have 2GB RAM which can get a little full (75% with VirtualBox and Chrome tabs) sometimes but does not seem to lead to performance issues in other applications
• I have a 120 GB SSD with 12.5 GB available at the moment, increasing available space to 15+GB did not seem to improve performance and again, I have not noticed performance issues in other applications
• I usually keep SourceTree running all day although that does not seem to matter much
• I usually have my bookmarks window open with 4 out of 22 of those being expanded (others hidden by closed groups)
• I am usually in Log mode viewing the history of all branches
• My main repo currently has 800+ revisions and is 14MB in size
• v1.3b3 shows the revision history after about 3s and the bottom panes after another second making 4s total
• v1.2.8.1 shows everything after about 2s
• Testing with another repo with 1400+ revisions and 400+MB had very similar returns so repo size does not seem to be a big factor
• Tests above were performed after starting up SourceTree then opening the test repo one time and closing it before closing it and opening it again while counting (one-Mississippi, two-Mississippi, ..)
• The initial repo loads seemed to perform similarly

[Peter Paul Ex Machina]

• v1.2.9.1 shows the revision history after about 5s and the bottom panes after another second or two making 6-7s total

[stevestreeting]

Thanks for the info - size isn't usually a speed factor until you start getting to seriously large (e.g. 100K commits or more), and your repo is smaller than the ones I'm using daily. 2GB RAM is smaller than I test with though. As I've mentioned to the other poster here, 90% of the delays I see in SourceTree are down to launching the git/hg processes, since these have to be scheduled and are susciptible to more variation in response time than simply running SourceTree code that's already in memory. Most of the time OS X is pretty good at this, since the hg/git binaries are very likely to be in Inactive memory which can easily be resurrected without having to reload anything from disk. However if RAM is short then it's increasingly likely that these are aggressively unloaded in favour of other apps, so maybe this is a factor. I cache and parallelise to try to amortise the cost of making these external calls but eventually they still have to be paid for.

For comparison, here (2.4GHz i5, 8GB, 10.7.2) 1.3b3 refreshes the SourceTree Mercurial repo history in just under 1s (measured with both a stopwatch and a code-level timer). My timing measurements identified that the Mercurial call was about 0.86s of that, with the rest being my processing and Cocoa. In comparison, on this machine 1.2.8.1 takes about 3-4 seconds. So 1.3b3 is 3-4x faster than 1.2.8.1 on this configuration.

It's possible that the parallelisation/asynchronous behaviour that I've added to achieve this isn't as benenficial on lower-end machines. I'm using Grand Central Dispatch which should adapt the number of active threads to the machine configuration. But perhaps this is preventing it from gaining the kind of benefit that offset the XCode 4.2 compiler change.

I would wonder if you'd see this resolved on Lion, but I also know that Lion's RAM requirements would make 2GB unworkable (I upgraded to 8GB b/c some things aren't very usable, like XCode). So, I'm stumped.

[Andrew]

Hi Steve,

Given the figures given by Etienne, which are all faster than my experience, even 2 seconds seems slow when other Mercurial interfaces on the Mac, list MacHG or the Mercurial Eclipse are pretty much instant. I assume these tool employ some sort of caching and pre-reading of the repositiory. From what I can see SourceTree is re-reading the whole repo history each time there is an update or your switch between views. Is that the case?

Kind regards,

Andrew.

[stevestreeting]

The log is completely rebuilt on refresh, yes - that's because things like MQ and rebase can make caching it very unreliable. SourceTree doesn't refresh when you switch views, only when you hit Cmd-R or it detects a file change in the history area of the .hg directory.

Please try the 1.3 beta in which I've deferred some of the refresh behaviour and eliminated a case of double-refresh. On my machine, it averages 0.7-1.5s, which basically matches the speed of 'hg log'. I'm constantly reviewing how I can make this faster.

It appears that on 10.6 things generally run a bit slower, which seems to be something to do with either the 10.7 SDK or the new LLVM 3.0 compiler, I'm not sure which, I'm getting mixed reports, but both seem to perform better on 10.7 over 10.6 with the same code.

[Andrew]

Where can I get the 1.3 beta?

Thanks

Andrew.

[stevestreeting]

http://www.sourcetreeapp.com/2011/11/21/sourcetree-1-3-public-beta/

You also can keep an eye on @sourcetree on Twitter for news like this.

[Barry Weinstein]

Regarding Andrew's video on 11/16 depicting the slowness, that is exactly the kind of response I get. I'm on a MacBook pro from 2009, running 10.6.8, 8 gig of ram, 75 gig free on the hard disk.

By the way, I also have the behavior that refreshes often don't happen automatically for me. I only mention it here if it provides any clue to the current issue.

[Barry Weinstein]

Just tried the beta. There is no improvement.

[stevestreeting]

There's probably a small difference but it seems the SDK / XCode version still has a majority effect on 10.6 it seems. The beta is built with the 10.7 SDK too (since the majority of users are now on Lion), which for some reason slows down the build on 10.6. I will try to find out why before the 1.3 final. This will be tracked here from now on: https://jira.atlassian.com/browse/SRCTREE-768

[etienned]

I tried your last version (10.6 SDK) and didn't see any improvment. To be sure, I've redo all the tests on another computer, a iMac 2009 2,93 GHz with plenty of free RAM and more then 400 GB of free space on the hard drive. I got mostly the same results:

• 1.2.9.1 -> 6 sec.
• 1.2.9.1 (python from 10.6) -> 6 sec.
• 1.2.9.1 (10.6 SDK) -> 6 sec.
• 1.2.8.1 -> 2 sec.

So, from my tests, it doesn't look that the problem is with the change from 10.6 to 10.7. Also 1.2.8.1 is definitely taking less CPU when refreshing and from what I can see, I don't think that the python subprocesses that's taking more CPU. Maybe it could be the process of launching this subprocesses or the communication with the main process that taking more CPU. I don't know?

[VSquash]

I will try to use 1.2.8.1 and let you know result.

[etienned]

I'm also using the last version 1.2.9.1 on OS X 10.6.8 and recently the changesets list (with mercurial) is very slow to refresh (6 sec. for a 600 changesets repo). When doing a refresh I see 3 Python processes but they're not taking a lot of CPU (0% in top). It was not slow at all 1 or 2 versions before.

Update

I just retry with version 1.2.8.1 and refreshing the same list take between 1 and 2 seconds. So there's cleary something that changed between 1.2.8.1 and 1.2.9.1 that cause that. Maybe it's related to this fix:

• Fix 'Current Branch' filter in Mercurial log view not displaying enough when current branch is very old

Or to themove to the 10.7 SDK?

[stevestreeting]

The thing is, I can't recreate this at all on 10.7.2 or 10.6.8 (an old 2007 MBP) - my refreshes are the same speed they were before. The people reporting this so far have been on 10.7 mostly, and low disk space has been a theme.

The 'Current Branch' change will if anything be slightly faster because while fixing it, I eliminated an extra Mercurial call. For me, the refresh of the log is the same speed between Current and All Branches.

My main day-to-day repo is about 2000 changesets in Mercurial and the refresh time on 1.2.9.1 is 1 second (MBP 2010 2.4 i5). If it's not the Python process / CPU that's taking the time, that does suggest something else is blocking, usually this is the disk, but it might be low memory. Perhaps the 10.7 SDK build stresses this more than before and you were on the cusp, I'm not sure - as I say perf between the two isn't noticeable for me.

The last thing I can think of is that I precompile all the Mecurial Python before distribution, but since 1.2.9 that probably defaulted to Python 2.7. I don't believe the bytecode is any different though, and as I said my 10.6.8 install works fine, but just in case, please try this test build: http://downloads.sourcetreeapp.com/SourceTree_test.zip

[VSquash]

I tried to use SourceTree_test.zip but no success. When listing revisions - A few Pythons process load processor for 100% and displaying list of revisions can take 10-20 seconds. I checked Hard Drive - there are 30+ GB free space.

I can record video how it's looking, if you want.

[stevestreeting]

I don't think just seeing it is going to help. I don't know why a small number of people are getting this.

As for 30GB free, it doesn't matter how much absolute space is free, it's the percentage. I'm not kidding - OS X performance drops off significantly at 10% free HDD space, I believe it's down to the automatic defragmentation.

[VSquash]

Ok. I can try to run defragmentation tool and look into results.

[stevestreeting]

@Vitalii: That's not really what I meant - if you have < 10% HDD space left, your machine is going to be slow at some things, it seems launching new processes is one of them (which SourceTree uses extensively because it has to call hg/git). I merely guessed that OS X's own continuous defrag might be a factor in that. I don't think manually defragging isn't going to fix that, freeing up more space is the only thing I've seen to fix it.

@Etienne: thanks for trying, at least that eliminates the Python version. I'll see if I can get a 1.2.9.1 build done with the 10.6 SDK so you can compare that. I moved to the 10.7 SDK later than most but I couldn't really put it off any longer, especially since I now have more Lion users than Snow Leopard and builds on 10.7 seem to run a little quicker there.

[etienned]

Thanks Steve for the answer.

I tried your test build and I got the same results as with 1.2.9.1, around 6 sec. I retried 1.2.8.1 just to be sure, and I still got around 2 sec. It's on a MBP 2007. I don't think it's a low memory problem because, when running my tests, I had around 1.5 GB of free memory. Neither a disk space problem, I have currently 17 GB of free space on a 100GB partition (of a 160 GB disk). I see no difference between 'Current Branch' and 'All Branches' in any version. In Activity Monitor or Top I rarely have the time to see the 3 python processes when running 1.2.8.1 but have plenty of time to see them with 1.2.9.1.

Sorry that I can't help more.

[VSquash]

I will try to use 1.2.8.1 and let you know result.

[VSquash]

Can someone provide link to 1.2.8.1 version ? So I can check does previous version really worked faster.

[stevestreeting]

http://downloads.sourcetreeapp.com/SourceTree_1.2.8.1.dmg

However, I would also urge you to try freeing up disk space if you're below 10% free space.

[stevestreeting]

@Etienne: Here's a build of 1.2.9.1, built using the 10.6 SDK instead, maybe you can compare to see how this behaves in comparison for you. Running it side-by-side here I see no difference (10.7, 2010 MBP) but maybe you will. If so, I'm not sure how I'm going to handle that since the App Store only allows one build.

http://downloads.sourcetreeapp.com/SourceTree_10.6SDK.zip

[Andrew]

Hi Steve,

I have just tried the build using the 10.6 SDK and it is quiet a bit quicker, still not as fast as I would expect but faster than shown in the screencast I shared.

Kind regards,

Andrew.

[VSquash]

It seems that 1.2.8.1 version really wokr faster. About 10.6SDK - I will try too and let you know.

[stevestreeting]

So it seems likely that merely building the same code with the 10.7 SDK makes it slower on Mac OS X 10.6, on some machines anyway. That's pretty disappointing, especially since I'll be adding more 10.7 features going forward. I have a couple of things I can try, but if they don't work I may make a 10.6 SDK build available in parallel officially in future, although not on the App Store.

[etienned]

I tried your last version (10.6 SDK) and didn't see any improvment. To be sure, I've redo all the tests on another computer, a iMac 2009 2,93 GHz with plenty of free RAM and more then 400 GB of free space on the hard drive. I got mostly the same results:

• 1.2.9.1 -> 6 sec.
• 1.2.9.1 (python from 10.6) -> 6 sec.
• 1.2.9.1 (10.6 SDK) -> 6 sec.
• 1.2.8.1 -> 2 sec.

So, from my tests, it doesn't look that the problem is with the change from 10.6 to 10.7. Also 1.2.8.1 is definitely taking less CPU when refreshing and from what I can see, I don't think that the python subprocesses that are taking more CPU. Maybe it could be the process of launching this subprocesses or the communication with the main process that taking more CPU. I don't know?

[stevestreeting]

Hmm, I'll see if I can track anything down in the differences. Really the changes between these 2 versions were not very significant, but maybe there's something hidden in there I've missed. Tracking here: https://jira.atlassian.com/browse/SRCTREE-768

[VSquash]

From my side I can confirm that version related to 10.6 SDK work faster. For me it works as fast as 1.2.8.1.

1.2.9.1 with 10.7 SDK works slow.

[etienned]

Reading the last comments, here my followup: for me 1.3.x is a bit faster than 1.2.9.1 but still slower than 1.2.8.1. I'm usually running Eclipse at the same time, so I redid my tests without Eclipse and didn't see any differences.

What I understand from all the comments is that the problem come from launching subprocesses. Maybe a solution, at least for th Mercurial side, would be to call the python code directly, use hg as a library. I know that MacHG work like this and it's pretty fast. I know also that's not trivial to made this change (embed mercurial, embed python, etc.).

[etienned]

Hi Steve,

Last message was almost 1 year ago but I still have the SourceTree slowness problem on 10.6 with HG using the latest version (1.5.5.1) (and now using an SSD with plenty of space and a lot of memory!). But just now I got the idea of using the "system" HG (v2.4) instead of the one embeded in SourceTree (v2.2.2), and now refresh and al. are alot faster. So the problem probably come from the fact the embeded HG is slow because it was not compiled for 10.6. I don't know exactly why, but Mercurial create a package for each Mac OS X version, so there's definitely a reason why it's preferable to compile HG specifially for each version.

[VSquash]

I'm using latest version 1.2.9.1 on Mac OS 10.6.8 and last few days I see that SourceTree working VERY slow. Our repositories has around 10k+ changesets, and when I'm looking at Activity Monitor I see that when I merging code - I see 3-4 Python processes which take 100% of the CPU and mergin working extremely slow. After merge it take too much time to display list of current changesets. 10-20 seconds. It works fater at least few weeks ago.

I can provide any information you need, but can this problem be investigated at some way ?

[stevestreeting]

Someone else reported something very similar recently (not this thread), but in the end the explanation was that their HDD was over 90% full. Please check this first.

Fundamentally very little has changed with SourceTree over the last few weeks, just minor bugfixes. 1.2.9+ is built with the 10.7 SDK but with 10.6 compatibility; I've tested this on 10.6 on a quite old machine (2007 MBP) and it ran fine though.

[stevestreeting]

Well, I had hoped it would be resolved for you, because 1.2.9 does optimise a few things for Lion. However, I rarely experience the sorts of slowness you reported on earlier versions either, so it was more of a hope.

I have found that since upgrading to Lion and XCode 4.2, the system slows down under load in general more than it did on Snow Leopard / XCode 3.2. Most of the time it's fine, but if I have a couple of projects loaded in XCode 4.2 and have been doing some debugging, I have definitely noticed that SourceTree slows down when you first switch back to it. So far, it appears that this is just down to swapping, because once SourceTree is back in the foreground it speeds up again on the 2nd/3rd refresh. Minimising my XCode load (only having one project open, being careful with very large IB files) seems to keep this under control. Most of the time, a Mercurial log refresh (Cmd-R) takes about 2 seconds, and a git log refresh about half that.

So IMO this is very much environmental. Launching new processes when the load on the system is high under Lion is definitely subject to more slowdown than Snow Leopard was (I get regular beachballs in Finder which I never got in Snow Leopard too - I'm hoping they improve this over time), and this hurts SourceTree when you first switch back to it.

If you're finding it intolerable, you might want to turn off the auto-refresh behaviour in Preferences and do it yourself with Cmd-R. If you have the bookmarks window open with a lot of bookmarks, and there's a chance that many of them may have updated, when you switch back to SourceTree there's a bunch of work it has to catch up on (SourceTree never does this when it's in the background to avoid hogging your system when you're doing something else). This can produce a spike in load - by making all refreshes manual you can control this better.

On my mid-2010 MBP (i5 2.4, 4GB, regular HDD), I don't see this sort of slowness on 10.7.2 so long as I don't load my system too hard. 1.2.9 improves things, but Lion is still generally more sluggish than SL for me (for all apps). You might want to check on your free HDD space to be sure, letting this drop below 10% can have a detrimental effect on your OS X performance in general.

[Andrew]

Hi Steve,

Thanks for your quick reply. I only have one bookmark and one local repository which is not massive. My system is a mid-2009 MacBook Pro with 8GB RAM and 250Gb SSD running 10.7.2 so I can't see from the description above why it would be so slow. I will do a Jing screencast of it for you and post you the link so you can see what I mean. I really like the software and would love to use it fulltime but at the moment I'm finding this is not possible.

Kind regards,

Andrew.

[stevestreeting]

So in all ways except CPU your machine is more powerful than mine. Can you run Activity Monitor to see what your CPU is doing?

[Andrew]

Hi Steve,

Sorry for the delay, I'm not sure if this is particularly helpful, but just to give you some idea of how slow I'm finding SourceTree please see the following screencast.

http://dl.dropbox.com/u/8706513/source-tree-slow-demo.swf

As you can see it takes about 10 seconds to retrieve the revision list, a couple to update the file list when clicking between revisions, even if you go back to one you have already viewed, and about 10 seconds again to switch to "file status" view. With the revision list it does the same after a commit, creating a branch, etc...

Kind regards,

Andrew.