• Post Reply Bookmark Topic Watch Topic
  • New Topic

performance of .class and constants

 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note: the following questions are with respect to the J2ME APIs, kVM, MIDP, etc. However, I'm not sure how different that implementation is from J2SE in the following issues.
Henry Clout (henry@YOSPACE.COM posted to KVM-INTEREST@JAVA.SUN.COM on Thursday, September 13, 2001 5:44 AM
[B]
- Adding final constants, even private finals, significantly increases code size - if you're really desperate to save code space you may consider using a pre-processor...?

- Using the .class syntax adds lots of code space. The compiler
generates a mew method which attempts to instantiate the given class, then throws a NoClassDefFoundError if, surprisingly, the class can't be found. It's far better to create an instance of the object to obtain its Class object, e.g.

[/B]


This doesn't seem right. In the first case, even if not inlined (which Peter Haggar has pointed out most compilers don't do very often), it should add that much extra overhead.
I'd also find it surprising that the first line of code above is faster. I'm not exactly sure what String.class does which is so expensive. In the second case, you have the cost of creating a new String (unless it was used elsewhere, and the object already exists in the String constant pool!).
Any thoughts?

--Mark
[This message has been edited by Mark Herschberg (edited September 13, 2001).]
 
Tim Osten
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Herschberg:
[B]Note: the following questions are with respect to the J2ME APIs, kVM, MIDP, etc. However, I'm not sure how different that implementation is from J2SE in the following issues.

[/B]


This doesn't seem right. In the first case, even if not inlined (which Peter Haggar has pointed out most compilers don't do very often), it should add that much extra overhead.
I'd also find it surprising that the first line of code above is faster. I'm not exactly sure what String.class does which is so expensive. In the second case, you have the cost of creating a new String (unless it was used elsewhere, and the object already exists in the String constant pool!).
Any thoughts?

--Mark
[This message has been edited by Mark Herschberg (edited September 13, 2001).][/B]
</BLOCKQUOTE>
Hi,
LITERAL VERSION - String.class;
INSTANCE VERSION - "".getClass();
Unfortunatley Henry is right.
The instance version runs
between 10 and 15 times faster than String.class. ( I even ran it with new String.getClass() and this is true)
If you don't believe me try it yourself.
I ran a test of 10000 iterations for each and "every" time
"".getClass() runs faster.
I would guess that this is because the literal version either has more code overhead or is dynamic(reflection?) in every execution ( I think that's what Henry was saying with
"The compiler generates a mew method which attempts to instantiate the given class"... I could be wrong) where the instance version just reuses compiled code.
The instance version will of course reference the "" String in the literal pool, referencing itself over and over.
This is interesting because it is not intuitive, however I have found no documentation explaining the actual cause of this. I looked through the Java Language Specification and Java Virtual Machine Spec and couldn't find anything on the .class literals performance. I think I'm going to ask this on in the sun Java forum and see what I get!!!
Anyway, those are my thoughts

 
Tim Osten
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I recant my last post Henry is incorrect!!!
I'm in the habit(bad habit) of running my code in VAJ
and it's there JVM that's wacked!!! the .class runs faster with jdk1.2.2 (reverse stats .class is 10-15 times faster than "".getClass() try it) though it would be interesting to see the performance on other JVM's !!! Whew!!!
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using the Sun JDK 1.3.1 compiler, String.class compiles toIf the String class has already been loaded, the statement String.class invokes a mere three-instruction sequence: getstatic, ifnonnull, getstatic. Compare this to the code for "".getClass():Only two instructions, but behind the method invocation are of course all the instructions of the String.getClass() implementation. So at least for J2SE 1.3.1, Henry Clout's assertion is false and using the class literal is preferable by far.
- Peter

[This message has been edited by Peter den Haan (edited September 26, 2001).]
 
Henry Clout
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My post on the KVM-INTEREST group concerned code space optimization -- I agree that it's not a particularly useful performance optimization.
As you can see, however, it does save a significant amount of code space -- in the case of String.class vs "".getClass()
it saves 419 bytes, mainly thanks to the removal of the extra static method. This probably isn't exactly a winning argument in the J2SE world, but in the sadly constrained
MIDP world this kind of saving can make a difference...
Henry
[This message has been edited by Henry Clout (edited September 27, 2001).]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!