Hello. > > [...] > I will try and do some benchmarking on this issue. I do not like these > "micro-optimizations" which tend to be true optimizations with one > version of the JVM, and are no longer with the next one. > Also, while we are at it, is there a benefit in defining a separate, > specialized method add(ArrayFieldVector<T>). The other option would be > to inline this method directly in the instanceof test in the general > add(FieldVector<T>). I guess the second solution would incur a slight > overhead in those cases when the compiler can resolve the actual type > of the parameter at compilation time.
Even if the actual type can be inferred at compile time, Java will not call the method with the most specific argument type (IIRC): ArrayFieldVector a = new ArrayFieldVector(); ArrayFieldVector b = new ArrayFieldVector(); FieldVector c = b; FieldVector f = a.add(b); // Will call "add(ArrayFieldVector)". FieldVector g = a.add(c); // Will call "add(FieldVector)". I.e. what counts is the declared type. This was the reason for having several add methods: if the declared type is "ArrayFieldVector", you gain one method call and/or you avoid the type check (instanceof). > But I'm not sure the gain is > worth the pain (again, the JIT seems to be pretty smart). If indeed the JIT compiler inlines everything (i.e. runtime analysis having shown which code path is actually run), then the nominal gain of one method call disappears (IIUC). If so, it would indeed be cleaner and more maintainable to remove the specific method (moving the specific code to the other one as you propose). [And it would also be more in accord with the best practice of programming by interfaces whereas, in Java, one had a strong incentive (performance) not to follow it. Maybe the contradiction doesn't exists anymore.] Best regards, Gilles > The drawback > of having two separate methods is that there is a little bit of > maintenance work in order to ensure that both have the same contract > (regarding, guess what, exceptions!). This is not a problem with the > general version of the method, which is specified in an > interface/abstract class. This is more problematic with the specific > version of the method. Of course, this only requires to be careful, > it's not so much of a hassle. > > Any thoughts on this? > Sébastien > > > > Regards, > > Gilles > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
