# Monday, 30 December 2002
« No Title | Main | 2 min 30 sec »
Eclipse Startup Perf

A large part of the startup time of Eclipse is caused by the overhead of producing stack traces for the about 25.000 ClassNotFoundExceptions that are thrown during startup (a really lame design of the Java class loader causes it to throw multiple ClassNotFoundExceptions for each class that is loaded). Java and .NET exception handling differ sufficiently that I have to do a lot of processing to build a stack trace for each exception that is thrown, and this is pretty expensive. As a test I decided to disable stack trace generation for ClassNotFoundExceptions and this reduces Eclipse startup time to 3 minutes! Note that this isn't entirely comparable to the 7 minute figure from Saturday, because various other things have also changed.

An alternative optimization that I investigated, was to add a hack the ClassLoader and URLClassLoader to reuse the exception object in URLClassLoader instead of throwing a new one, this also saved a significant amount of time. I'm wondering how others feel about this optimization? It consists of two changes: 1)ClassLoader.loadClass() calls ClassLoader.findClassFast(String name, ClassNotFoundException e) which calls ClassLoader.findClass(), 2) URLClassLoader overrides findClassFast and does a check to see if it has been subclassed, if not it calls findClassImpl and passes it the exception object it got from loadClass, if it has been subclassed it call URLClassLoader.findClass which calls findClassImpl with null as the exception object.

We're not there yet, but progress is being made :-)

Monday, 30 December 2002 18:00:08 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
Monday, 30 December 2002 13:50:53 (W. Europe Standard Time, UTC+01:00)

Interesting observation. But what processing are you doing at Throwable creation time?
In my view you should only record the state (the original .NET exception) and only
generate the stack trace when it is really needed (when getStackTrace() is called).
Most of the time the real stacktrace is discarded anyway.

Your optimization is interesting (and saves object creation) but it would mean changing
the public API which is not something I would do lightly.

I would really like to have this conversation on the (classpath) mailinglist.
That one is archived in more places and a public mailinglist or newsgroup is still
my preferred way of discussing technical topics (if it cannot be done in person).
And please post a patch so others can easily play with your hack.

Tuesday, 31 December 2002 12:39:14 (W. Europe Standard Time, UTC+01:00)

OK, will do.
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview