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.
The latest beta, 1.3b3, has solved this issue and the listing are now super quick. Excellent work, thanks very much.
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.
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.
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?
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 ?
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.
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:
Or to themove to the 10.7 SDK?
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
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.
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.
I will try to use 1.2.8.1 and let you know result.
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...
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:
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?
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?
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.
Where can I get the 1.3 beta?
Thanks
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.
Awesome, I was hoping it would! Thanks for letting me know.
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)
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.
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.
I understand this is a difficult to reproduce and thus fix issue. Let me give you some more info to work with:
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.
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)).
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
"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)
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.
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.
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.
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!
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.
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?
It looks like you're new here. Sign in or register to get started.
