On Mon, 2004-01-26 at 17:45, Andreas L. Delmelle wrote: > > -----Original Message----- > > From: Finn Bock [mailto:[EMAIL PROTECTED] > > > The result is then: > > > > [/d/fop] /c/java/jdk1.2.2/jre/bin/java.exe -cp . x > > false method call 581 > > true method call 581 > > false instanceof 160 > > true instanceof 170 > > > > [/d/fop] /c/java/jdk1.3.1_03/jre/bin/java.exe -cp . x > > false method call 1272 > > true method call 2304 > > false instanceof 17945 > > true instanceof 912 > > > > [/d/fop] /c/java/j2sdk1.4.2_02/bin/java.exe -cp . x > > false method call 2154 > > true method call 2754 > > false instanceof 590 > > true instanceof 651 > > > > Very, very interesting... Java's OO-optimization at its best (except for > 1.3)! After all, it shouldn't be *that* surprising that an > accessor-method-call generates more overhead than a test for > class-membership (but what if the class in question is not yet loaded at > time? Not that this should occur a lot...)
So I copied that program and ran it on my RH 9 system. Got the following results. I am just quoting the results here: Note that the default JVM is -client or HotSpot ... [EMAIL PROTECTED] foptest]$ java -classpath . x false method call 998 true method call 1001 false instanceof 3008 true instanceof 4119 [EMAIL PROTECTED] foptest]$ java -server -classpath . x false method call 1 true method call 0 false instanceof 0 true instanceof 4822 [EMAIL PROTECTED] foptest]$ java -server x false method call 1 true method call 0 false instanceof 0 true instanceof 4784 java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode) Hmmmm. -- John Austin <[EMAIL PROTECTED]>
