here is the huge performance boost: Every single time I deserialized an object, it has to do a cl.loadClass(), now using a custom object stream, it would search the WCL first, then the SCL. And since it didn't exist in WCL, it still seemed to do a long scan each time, and then defaulting back to SCL at which point it was fast.
By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe told me, I trust him :) Is this scenario clear? Filip ----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, August 05, 2004 11:01 AM Subject: Re: StandardClassLoader ? Filip Hanik - Dev wrote: >During session replication I optimized my code to decide what order class loader to >use based on the class name. > >For example, if you load a class that starts with org.apache.catalina. I attempt to >load it with the SCL first, it gave the app a >huge performance boost. > >I know I know, this breaks the rule of thumb with webapps, but there are smart >shortcuts you can make, like make a list of all the >classes in common/lib and server/lib and never load those through WebCL unless >specified by the user. Most user would love the >performance gain of this, and the ability to turn it on/off > > This is extremely easy to test: you need to add stuff to the package array in WCL, so that it will delegate for these packages. This doesn't improve performance in any noticeable way (as I expected), so I don't see where you found any huge performance boost. While it does sound great, I think your test seemed either bad or very specific. From my profile, the bottleneck for the startup time is XML parsing and accessing entries in JARs (we can't do anything about that), with a little for classloading as well (but it's not very big, and my optimization plans were to experiment loading everything at once on stratup, to be able to remove all syncing in the CL - I don't even know if that would have been efficient, and since it does conflict with the more interesting stuff from Costin, I'm giving up on that one for now). Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
