This is interesting. I posted a link to a state-machine-based UTF8 parser/recognizer:
I spent some time thinking if the lookup table could be converted into a stateless computational function, which would avoid a table lookup (which in Java will cause an additional bounds check that will be hard to eliminate I think). This didn't turn out to be easy (it boils down to finding a simple function that would map a set of integers to its concrete permutation; a generalization of minimal perfect hashing).
But out of curiosity I though it'd be fun to compare how Lucene's codepoint counting compares to Java's built-in one (Decoder) and a sequence of if's.
I've put together a Caliper benchmark that processes 50 million unicode codepoints; one only ASCII, one Unicode. The results are interesting. On my win/I7:
Disregard the switch lookup – it's for fun only. But a sequence of if's is significantly faster than the current Lucene's table lookup, especially on ASCII input. And now compare this to Java's built-in decoder...
Yes, it's the same benchmark. Wtf? I realize buffers are partially native and probably so is utf8 decoder but by so much?! Again, to put it in context:
Wtf? The code is here if you want to experiment.
I realize the Java version needs to allocate a temporary space buffer but if these numbers hold for different VMs it may actually be worth it...
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|22h 14m||1||Dawid Weiss||28/Mar/13 08:45|
|43d 1h 48m||1||Uwe Schindler||10/May/13 10:33|
|Status||Resolved [ 5 ]||Closed [ 6 ]|
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Fix Version/s||4.3 [ 12324143 ]|
|Resolution||Fixed [ 1 ]|