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

[Bill Burke]

Plus, despite what yall might think i'm not a total idiot...

ZipInputStream for a 5m file may take 256, may take 286, may take 249. 
In fact if you expand out most of these micro tests, you still get the 
same percentage difference.  Thats because any GC or thread scheduler 
will only effect measurements by a few milliseconds in such a small test.

Another thing that took off about 15ms +/- was removing inner loop use 
of Iterator and replacing it with an old school index loop:

for ( x : y) replaced with for (int i = 0; i < size; i++)

for (x :y) with collections creates an object (the Iterator) plus 
invoked a few methods (hasNext() and next()).  Might seem stupid, but if 
you're doing this thousands and thousands of times, it adds up.  Its too 
bad the compiler doesn't see this.

Anyways...

While its not worth looking into saving 30ms here or there right now, it 
will be worth it after we get the low hanging fruit optimized (AOP, 
dsorting, VFS2->3 migration).  I know we can get boot time under 5 
seconds for the default profile.  How do I know that?  3 years ago I had 
embeddable JBoss booting with MC, VDF, JCA, HypersonicDB, Jndi, EJB3, 
Hibernate, TX, and JMS in under 5 seconds with zero optimizations.  My 
bet is that we can get these components plus JBoss Web for a stripped 
down dev profile (no profile service, management, hotdeploy, aop, bsh, 
etc.) in less than 2 seconds with further deep optimizations.  In the 
end we'll have something that is testable, embeddable, and something 
that totally removes the need for stupid Mock shit.


Emmanuel Bernard wrote:
> OTOH if the test last minutes, this is not a realistic test either. The bootstrap of AS is the bootstrap of AS, the VM starts from cold that's a fact of life.
> 
> On 8 janv. 2010, at 14:56, Richard Opalka wrote:
> 
>> He, hold on here Bill.
>>
>> If you want to measure performance, you have to have huge testing set.
>> Playing with milliseconds doesn't prove anything :(
>> If you measure:
>>
>> ZipInputStream: 256ms.
>> URLClassLoader: 5ms.
>>
>> it doesn't prove anything. ZipInputStream could be affected by thread 
>> scheduler and as such not active for some (e.g. 255 ms) time.
>> To prove something is unefficient (e.g. VFS3),
>> you have to create tests that will measure performance in 
>> seconds/minutes to measurement don't be affected by thread scheduler or GC.
>>
>> Rio
>>
>> On 01/05/2010 06:18 PM, Bill Burke wrote:
>>> A simple test of using ZipInputStream vs. URLClassLoader to find a
>>> resource within jacorb.jar.
>>>
>>> ZipInputStream: 256ms.
>>> URLClassLoader: 5ms.
>>>
>>> URLClasLoader is obviously using some other mechanism to find things.
>>>
>> -- 
>>
>> Richard Opalka
>> ropalka at redhat.com
>> JBoss, by Red Hat
>>
>> Office: +420 222 365 200
>> Mobile: +420 731 186 942
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> 
> _______________________________________________
> 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