As Rich says, a cache would probably destroy the performance. The current prerequisite to optimizing away boxed parameters, is that the JVM can inline the function call and the JVM usually inlines a lot! It can even inline code that C++ cannot, i.e. code that is virtual. It avoids code bloat by only inlining code that is hot. And if the code is not hot, it does not matter if it uses autoboxing.
You can see an example of how efficient the generated machine code can be, despite excessive autoboxing, here: http://blogs.oracle.com/ohrstrom/2009/05/pulling_a_machine_code_rabbit.html //Fredrik 2009/8/4 Rich Hickey <richhic...@gmail.com>: > A number might be boxed, passed into a nested call, passed to > another... then used in a calculation and never escape. The optimizer > could (potentially) see that whole chain and avoid the box throughout > the call sequence, inline it etc. > > But none of that matters to the cache case, because the cache-using > code says "either use the Integer value found when looking up 42 in > this hash table, or, if missing, the new Integer(42)". It can't > unconditionally replace that with the primitive 42, since it has no > idea what Integer is in the hashtable at key 42 (i.e. it doesn't know > that the value at that key _is_ Integer(42)). So it can't remove the > box, nor avoid the lookup. > > Rich > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
