On 20/04/2011 16:51, Konstantin Kolinko wrote: > 2011/4/20 <ma...@apache.org>: >> Author: markt >> Date: Wed Apr 20 11:28:53 2011 >> New Revision: 1095367 >> >> URL: http://svn.apache.org/viewvc?rev=1095367&view=rev >> Log: >> Switch JAR scanning to use JarInputStream rather JarFile for significant >> startup performance improvements >> > > >> + <fix> >> + While scanning JARs for TLDs and fragments, avoid using JarFile and >> use >> + JarInputStream as in most circumstances where JARs are scanned, >> JarFile >> + will create a temporary copy of the JAR rather than using the >> resource >> + directly. This change significantly improves startup performance for >> + applications with lots of JARs to be scanned. (markt) >> + </fix> > >> + // JarURLConnection#getJarFile() creates temporary copies of >> the JAR >> + // if the underlying resource is not a file URL. That can be >> slow so > > What URLs are there? Why aren't they file ones?
Resources obtained via the context are jndi URLs. > A zip file has "central directory" i.e. master index at the end of the > file. IIRC when you are using random-access methods of Zip file, that > index is loaded into memory once. Scanning the file sequentially does > not use the index and I think it will be slower. Old code: - read entire file (sequentially) - write entire file to temp location - read required data from file New code: - read file sequentially until we find the bit we want. On a reasonably complex app with quite a few JARs the start-up time went from ~30s to ~12s with these changes with most of the 12s now being app init code. Copying the file was killing performance. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
