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

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(a)redhat.com >> JBoss, by Red Hat >> >> Office: +420 222 365 200 >> Mobile: +420 731 186 942 >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development