If you install a nightly after .... well ... this instant ... there is
a new feature (that hopefully will move into Eclipse core). If you
run OS X Leopard, the implementation of the workspace refresh provider
has switched from the default polling to one based on the Leopard File
System Events API (this is basically the same API that lets Finder
refresh immediately when you make a change to your files). This
should result in vastly better performance (no more polling = less
laptop fan :) ) and refreshing should be very fast. The
implementation currently has a 1 second max delay (to allow for
coalescing), though I might drop this lower after some testing. This
means that after touching the filesystem, it will be at most 1 second
before the change appears (and possibly nearly immediate). There is a
little more work to do, however, because the default eclipse
implementation of responding to a refresh command is to do a subtree
scan, whereas with FSEvents we actually know whether or not we have to
do that (at best, and usually the case, we only need to do a single
container scan). This is going to take some API changes in Eclipse to
support this change, though. Even without that, it's still pretty
good, though, as most of your time is spent changing files in packages
and components (which tend to not be deep trees). The worst case of
this is if you change a file in the project root, which will
essentially be no worse than the previous implementation (well, better
because it doesn't CONSTANTLY do it).
So the downside of this is that there's a new hunk of JNI code in
there, written by a mostly-Java-guy, so there's potential for a series
of explosions. I've been using it for a little while now without any
problems, and the high-risk points are usually startup and shutdown,
so you'll probably know pretty fast if it breaks. So if you install
the new build and your Eclipse dies on you .... I might be partially
responsible. Let me know.
Next up is to start looking at the build process ... On systems that
support symbolic links, I believe it will substantially increase the
build speed to change the build process to use symlinks instead of
copies. In fact, if you use fluffy bunny, WebServerResources (as an
example) can be symlinked in a single step. The nice thing about
switching to symlinks is that it also means that files like d2wmodels
will be "live" so that changes will reflect immediately and will also
be available to the assistant for editing.
ms
This archive was generated by hypermail 2.0.0 : Mon Jun 16 2008 - 01:24:09 EDT