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

[John Bailey]

Moved the sysouts to the end.  Here are some sample runs.  The warm up effect may just be environmental.  

Five runs with no warm up:
1.   	Get Provider: 		137
	Mount Zip: 		111
	Determine Packages: 	77
2.	Get Provider:		133
	Mount Zip: 		93
	Determine Packages: 	75
3.	Get Provider: 		122
	Mount Zip: 		174
	Determine Packages: 	73
4.	Get Provider: 		109
	Mount Zip: 		96
	Determine Packages: 	73
5.  	Get Provider: 		134
	Mount Zip: 		117
	Determine Packages: 	65
Five runs with warm up:
1.		Get Provider: 		80
	Mount Zip: 		109
	Determine Packages: 	67
2.	Get Provider: 		83
	Mount Zip: 		86
	Determine Packages: 	82
3.	Get Provider: 		82
	Mount Zip: 		87
	Determine Packages: 	79
4.	Get Provider: 		78
	Mount Zip: 		94
	Determine Packages: 	63
5.	Get Provider: 		83
	Mount Zip: 		86
	Determine Packages: 	72




On Jan 5, 2010, at 2:43 PM, Bill Burke wrote:

> 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
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

--
  John Bailey
  JBoss by Red Hat
--




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20100105/09ef343e/attachment.html