The last couple of release of Subclipse in the 1.1.x series have included
some performance tweaks. I am interested to know if anyone is noticing
them. There are so many variables that go into performance that is
sometimes hard to know how big of a difference they make. So here are
some of the areas where performance should be improved:
1) Startup
This was in the 1.1.3 release. At startup we would run a non-recusive svn
status on each SVN project in your workspace. If you had a lot of
projects or the root folder of any of them was large, this could add a
noticeable number of seconds to the startup. You should be seeing Eclipse
start and show the project decorators faster. The CVS code has something
similar, it probably just runs faster. A by-product of this change would
be if you had a project in your workspace that was no longer a SVN working
copy when you restarted, you will get some errors. That does not seem
like a problem with coding or and paying a performance price.
2) Decorator/status refresh #1
This is in the 1.1.5 release. It probably only effects people using
svn:externals. When we refresh the status of a modified item, SVN returns
a structure that includes the URL of the item in the repository. If that
URL is null (which is the case for an svn:externals folder) then we run
the svn info command to get the URL. It turns out that the method we were
calling will contact the repository for some reason. People using
GoogleCode which initially had 60+ second response time were really
noticing this. So we fixed it to use a method that runs purely local. If
you are using a slow repository, and this code gets used more than we
think, then this should give a noticeable improvement.
3) Decorator/status refresh #2
This is also in the 1.1.5 release. A lot of you are reporting problems
when doing Ant/Maven builds. This happens when Eclipse refreshes the
workspace and sends all of those modified files through the change
listener process. Similar things could happen when doing Project ->
Clean. The process of discovering that these items are
ignored/unversioned can take a while and tie things up. We think we have
made some changes that should make this faster. From an API point of
view, it is easy to see that we are making a lot less svn status calls
after this change. It is still hard to quantify what this translated to
in real world usage. We have some ideas for some more radical changes we
could make, but hopefully this change will provide some immediate relief.
4) Synchronize
This is also in the 1.1.5 release. Martin Letenay is profiling the Synch
process and looking for ways to speed it up. We have one optimization in
this release, It is a low level change in just how we are
constructing/storing data, but the profiler showed it being one of the
main things done in the process. Martin says the svn status fetching
makes up only about 25% of the total time in Synch, the rest is all
Eclipse fetching files etc. So we think we can make more improvements,
and this release includes the first.
A lot of people are linking #3 to Synchronize, but from my testing it is
not the case. You are probably just doing Synchronize right after doing a
build and what you were seeing was a status update process that had
already begun. Anyway, it would be good to receive some validation that
these changes are making a difference that you can see in the real world.
Thanks
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Tue Aug 8 21:03:47 2006