nano cost for simple virtual calls and object casts
Andy Nuss
andrew_nuss at yahoo.com
Wed Sep 5 09:00:39 PDT 2012
Hi,
I am writing an automata, for a specialized regex/parser-generator scripting grammar, even though java.util.regex and antlr are great, I'm doing something a little different, with different matching powers. I wrote an experimental version of my automata, same essential code in both C++ and java, and my automata execution speed per character, not counting overhead, was 3x to 6x faster in the C++ version.
Because for many reasons, as with Antlr, this matching engine has to be for java, then so do its automata, and writing a native function for just the automata is not really a good solution overall.
So I was trying to get at the root cause of slowness in the java hotspot compiled version. I wrote a careful test for the nanosecond overhead of "virtual" calls to what would otherwise be simple inlineable methods. That came out to about 0.5 nanos (0.7 for interface calls). Also, I profiled several kinds of object casts, and that was 0.4 nanos. By the way, using an iterative loop to copy very simple array elems was used as a baseline, and the array elem copy cost was about 0.5 nanos per object.
As it relates to my data structures in the automata execution function bottleneck, there are for each character transition possibly many "vtable" calls and possibly many "casts". The "casts" are in my case principally due to the use of generics, and in particular my several generic linked lists on elem T. All these half nano costs add up, and slow down the engine in java relative to the C++ version where static_casts are like nops and I think simple virtual calls are much faster. (As to arrays, there's not much that can be done.) My todo is therefore, redesign a little to ensure that there are no virtual calls for what would otherwise be inlineable methods. For the many types of linked lists used, I have no choice but to manually "bloat" the linked list methods out of List<T> and into each list class.
Question: does casting really have to be so expensive in java and why? is there any way to reduce the overhead of simple "virtual" calls of abstract classes, possibly at the expense of interface calls?
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120905/6c88170e/attachment.html
More information about the hotspot-compiler-dev
mailing list