You should move the System.out.println("Mount Zip...") to the end as it
will screw up timings.
BTW, "warming up the JVM" has absolutely no effect on my timings.
John Bailey wrote:
The recursive mounting is really for Zip files nested within Zip files. So in this case there is no need.
Here is the code I have been testing:
---
public class PackageVisitorTestCase extends BaseTestCase
{
public PackageVisitorTestCase(String s)
{
super(s);
}
public void testPackageVisitor() throws Exception
{
Thread.sleep(1000);
URL url = Thread.currentThread().getContextClassLoader().getResource("jacorb.jar");
TempFileProvider provider = null;
Closeable handle = null;
try {
long start = System.currentTimeMillis();
provider = TempFileProvider.create("test", Executors.newScheduledThreadPool(2));
System.out.println("Get Provider: " + (System.currentTimeMillis() - start));
VirtualFile jarFile = VFS.getChild(url);
start = System.currentTimeMillis();
handle = VFS.mountZip(jarFile.getPhysicalFile(), jarFile, provider);
System.out.println("Mount Zip: " + (System.currentTimeMillis() - start));
VirtualFile[] roots = {jarFile};
start = System.currentTimeMillis();
Set<String> pkgs = PackageVisitor.determineAllPackages(roots, null, ExportAll.ALL, null, null, null);
System.out.println("Determine Packages: " + (System.currentTimeMillis() - start));
}
finally {
VFSUtils.safeClose(handle, provider);
}
}
}
On Jan 5, 2010, at 2:24 PM, Bill Burke wrote:
John Bailey wrote:
I have been running the tests through JProfiler. Not sure if I just have not optimized the profilers settings, but I am getting numbers all over the board, and some are well over double the time of a JUnit execution. The non-profiler time to run the test seems to be <300ms.
With the profiler enable, I can see ~30% of the total time is in the VFS.mountZip call. With >10% of the total test time taken up by the 5,085 calls to org.jboss.vfs.util.PathTokenizer.getTokens.
The org.jboss.classloading.plugins.vfs.PackageVisitor.determineAllPackages call is taking ~35% of the total test time to run. With ~14% of the total test time in VirutalFile.isDirectory.
Ya, JProfiler is all over the place for me too.
I did currentTimeMillis() timing VFS init took 179/252ms if I don't do
children recursive mount. 420/456ms if I do do recursive child mount.
(Maybe children are getting initialized/cached or something with the
recursive child mount).
Maybe there is room for more caching of this isDirectory like calls. There may be a problem with caching the info as the actual file system can change for a given VirutalFile, and the cached information is not guaranteed to remain accurate.
Should be fine to cache for a jar? VirtualFile could ask the FileSystem
if its cacheable or not.
Or, even better, you could have parallel non-cached getters that could
be used by sensitive logic (like a deploy/ directory scanner). If a
non-cached getter detects a new value, it invalidates the entire cache.
i.e.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
John Bailey
JBoss by Red Hat
--
_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development