Am 09.02.2012 18:17, schrieb Jochen Theodorou:
[...]
Example:
Object plus(Object x, Object y) { // we expect this function to inline
and customize
if (x instanceof Integer&& y instanceof Integer) return (int)x + (int)y;
return slowPlus(x, y); // slow path is out-of-line
}
Will a method like this:
public Number addImpl(Number left, Number right) {
return Integer.valueOf(left.intValue() + right.intValue());
}
be ok as well? I mean will the JIT still be able to remove the boxing?
from my first test I think I can tell that this method is not ok. While
not being very bad, it does not benefit from removed boxing or such.
Your Version does btw, not compiler, you cannot cast to int, it has to
be Integer. Small mistake I guess. Anyway, your approach seems to work,
but I wonder if that is the right way for me as well.
One odd thing I noticed is that if I make a plus(Integer,Integer):Object
and compare it with a plus(Integer,Integer):Integer method, then this
later version seems to perform quite a bit slower. Sure, yes, the call
site expects Object, so most probably a cast is needed here. But
still... should that really cost my almost 20% of my performance?
My problem with the math operations is not really solved btw. If I use
the fast/slow path approach I get into problems with other types. So
imho that makes sense if you look at int driven programs a lot. But what
if there is also long and double? Soon there will be the point in which
the JIT cannot inline it any more and when this point is reached depends
on more than this function alone I would assume. Inlining is done not
always, even if the method is small. There has to be also "space" for it
in the target. And the bigger and more functions I have like that, the
less often inlining happens.
I hope someone will correct the statement if it is totally off.
But going by this I seem to be better of with specialized functions for
int, double and long... only that in mixed operations I still have the
problem of conversion. My test kind of show my that if
explicitCastArguments is doing the conversion it is not going to be nice.
bye Jochen
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
