 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Virtual Machine / October 2005optimizing code
I am writing code that I would like to be fast. When are method calls not virtual? I could guess for static methods, constructors... any other? private methods? final methods? I would like to avoid the extra lookup into the "VTAB". thanks, Andersen > I am writing code that I would like to be fast. > When are method calls not virtual? I could guess for static methods, > constructors... any other? private methods? final methods? All methods in Java are virtual. >> I am writing code that I would like to be fast. >> When are method calls not virtual? I could guess for static methods, >> constructors... any other? private methods? final methods? > > All methods in Java are virtual. But the VM can do some optimizations (inlining) for methods that are known to be unoverridable (static, private, final methods). But: premature optimization is evil. OP, first implement it properly modeled and then measure performance and optimize. Kind regards robert FUP to comp.lang.java.programmer > All methods in Java are virtual. Is this true? Class methods are not looked up but rather directly invoced! Same goes for constructors. Which is why you cannot override them while still having the "virtual" property that calling a Super.Method(); would always resolve to the super class rather than to the actual method implemented in the object (which might be a subclass with a overridden method). >All methods in Java are virtual. Static methods are not virtual. Instance methods in a base class are not. In the JVM are instructions called: invokestatic invokevirtual invokeinterface invokespecial (née invokenonvirtual)  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >Instance methods in a base class are >not. oops. I should have said private or final instance methods in a base class are non-virtual. final instance methods may or may not be virtual in a subclass, depending on whether they override. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >I am writing code that I would like to be fast. >When are method calls not virtual? I could guess for static methods, >constructors... any other? private methods? final methods? For an interpreter, finals are faster than virtuals; class references are faster than interface references; static references are faster than instance. However, those are not usually things you can change without butchering the logic (other than adding final). Adding final does not help for a smart runtime that effectively adds them for you where possible, e.g. java -server or Jet. see http://mindprod.com/jgloss/optimising.html http://mindprod.com/jgloss/optimiser.html http://mindprod.com/jgloss/jet.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >>I am writing code that I would like to be fast. >>When are method calls not virtual? I could guess for static methods, [quoted text clipped - 4 lines] > are faster than interface references; static references are faster > than instance. Are local references faster than instance? I noticed copying instance Objects to local before repeated references in some (early) source from Sun, in particular, many of the String methods copied the char[] to local before looping through it. Perhaps that's of benefit only for interpreted execution? Of course, some JVMs will interpret a method several times (32 times in one I've seen) before JITCing it. --Mike Amling > Are local references faster than instance? I noticed copying instance > Objects to local before repeated references in some (early) source from > Sun, in particular, many of the String methods copied the char[] to > local before looping through it. Perhaps that's of benefit only for > interpreted execution? You would expect the (bytecode to native) compiler to be able to optimise field loads into registers. This might not happen if the compiler isn't powerful enough, can't be sure there is no aliasing (multiple references pointing to the same object) or it is not inlining everything in between uses. > Of course, some JVMs will interpret a method several times (32 times > in one I've seen) before JITCing it. Sun's client (C1) JVM does 1,500 iteration before compiling by default. The server (C2) JVM 10,000 iterations. Methods may get partially optimised and then recompiled. Tom Hawtin [Followup-To: comp.lang.java.programmer] SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > Are local references faster than instance? considerably so. Further the first-defined locals are faster still (unless some optimising renumbers them) You will often see sun copying into locals, doing some work and copying back into instances. The faster speed of the locals often makes up for the copies. Further such code is less prone to thread problems. The optimiser could be inhibited by worrying about some other thread changing the instances. When you use the locals, that reassures the compiler you don't care if some other thread subsequently changes them, and so does not inhibit the obvious optimisations. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. >For an interpreter, finals are faster than virtuals; class references >are faster than interface references; static references are faster >than instance. That sounds interesting. Can you point me to some benchmark data ? David J ---------------------------------------------------------------------------------- http://KickJava.com - Java Examples, Source Codes, Free Online Books, News and Aricles >>For an interpreter, finals are faster than virtuals; class references >>are faster than interface references; static references are faster >>than instance. > >That sounds interesting. Can you point me to some benchmark data ? Sorry no. You would have to create some. Just think about how you would write the equivalent code in assembler. You might dig around for the principles of operation of some JVM interpreting hardware and look at the cycle counts on the various op codes. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts. > That sounds interesting. Can you point me to some benchmark data ? There are lies, damn lies, and ... I've been doing a lot of low level benchmarking lately (method invocation and stuff) lately, and it's pretty hard to do reliable benchmarks on the (esp. HotSpot) JVM, simply because there are so many nuances and things going on under the hood you need to account for. It's easy to write tests that test things you didn't mean to test, if you know what I mean. You also have to consider things like GC, which can kick in and skew your results quite badly. This seems to be a decent introduction: http://www.concentric.net/~Ttwang/tech/microbench.htm I suspect you'll struggle to find any actual numbers, simply because these things are so changeable that it's difficult to come up with anything definitive. SignatureRoss Bamford - rosco@roscopeco.remove.co.uk >> For an interpreter, finals are faster than virtuals; class references >> are faster than interface references; static references are faster [quoted text clipped - 3 lines] > > David J ------------------------------------------------------------------------------ > ---- > http://KickJava.com - Java Examples, Source Codes, Free Online Books, > News and Aricles dig out a book "hardcore java" by oreilly. there is a lot of interesting optimizations in there. including finals. Steve >I am writing code that I would like to be fast. > When are method calls not virtual? I could guess for static methods, [quoted text clipped - 4 lines] > thanks, > Andersen Optimizations at the source level are of little value to Java. The compilers also generate very simple bytecodes with no optimizations. The power of Java comes from the JITs. These can (depending on your VM/JIT and JIT mode) dynamically profile frequently executed code and compile them to run an order of magnitude faster. Most performance gains are achieved after that by thoughtful selection of the appropriate algorithm for your problem. There are small gains to be had with final methods and static methods, but these are typically swamped by other changes. There are also a collection of optimizations that are related to limiting memory allocations - "new" (GC's can be expensive), using the correct classes when manipulating strings (they are immutable, so editing them creates new copies under the covers), and avoiding use of exceptions as a frequent expected execution path (exception handling can be time consuming). There are ways to make numerical algorithms faster as well, but you need to tell us what type of application has the need for speed. There can also be start-up time concerns. Anyone using a large Java application such as Eclipse can testify to that. These marginal optimizations that you mentioned are not very valuable, unless you are on a platform without a JIT and already have really tight time constraints. Mark... > I am writing code that I would like to be fast. > When are method calls not virtual? I could guess for static methods, > constructors... any other? private methods? final methods? > > I would like to avoid the extra lookup into the "VTAB". If you're interested in faster Java code, see the IBM Systems Journal, Vol. 39, No. 1, issued in 2000. --Mike Amling Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.