Good point about equals, I'm just thinking in a tight render loop (like in a game engine or something equally as sensitive) even with the diff hash codes you are dropping through to a char-to-char comparison IN the off chance that your two strings are the same length.
I'll be the first to admit those are pretty slim odds, but it's always fun to dig up these little performance things hidden in the JVM and store them away for later use in some interesting project.
Nice decompile with the enums... no idea what's with the array either; another hidden gem to at least be aware of.
This is alot like when autoboxing came out. New Java people thought int i and Integer ii were the same when used in different settings, not realizing that under the covers Integer.valueOf(i) and ii.intValue() are getting generated.
It's great if valueOf is returning a cached value (-127 to 128) but beyond that you are just object-creating all over the place.
Working on SJXP (xml parser layer that sits ontop of Pull Parser to make it like XPath, but super fast) I did some HPROF and found my use of path hashcode lookups in a Map<Integer, String> was generating millions of Objects.
So I moved to an Integer cache that holds the Integer object generated from the hashCode() and re-uses it as needed.
Ended up dropping the overhead (CPU and memory) of the library below everything in native XPP to where it adds almost no overhead.
Anyway -- thanks for diving deep with me on that, we have two new tricks up our sleeves ;)
I'll be the first to admit those are pretty slim odds, but it's always fun to dig up these little performance things hidden in the JVM and store them away for later use in some interesting project.
Nice decompile with the enums... no idea what's with the array either; another hidden gem to at least be aware of.
This is alot like when autoboxing came out. New Java people thought int i and Integer ii were the same when used in different settings, not realizing that under the covers Integer.valueOf(i) and ii.intValue() are getting generated.
It's great if valueOf is returning a cached value (-127 to 128) but beyond that you are just object-creating all over the place.
Working on SJXP (xml parser layer that sits ontop of Pull Parser to make it like XPath, but super fast) I did some HPROF and found my use of path hashcode lookups in a Map<Integer, String> was generating millions of Objects.
So I moved to an Integer cache that holds the Integer object generated from the hashCode() and re-uses it as needed.
Ended up dropping the overhead (CPU and memory) of the library below everything in native XPP to where it adds almost no overhead.
Anyway -- thanks for diving deep with me on that, we have two new tricks up our sleeves ;)