[jboss-dev] Further profling: Where should I focus?

[Bill Burke]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> --
>   John Bailey
>   JBoss by Red Hat
> --
> 
> 
> 
> 
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com