Very cool!
On Jun 15, 2008, at 10:23 PM, Mike Schrag wrote:
> 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
>
>
--Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
This archive was generated by hypermail 2.0.0 : Mon Jun 16 2008 - 12:20:22 EDT