Charles Oliver Nutter schrieb:

what means valid? If I add so much optimizations that the compiler will run ten times slower then it is still valid, but not desired. For example I could add dynamic branch prediction to my if-else-cascade, that is possibly much faster if the values do not change too much. Hotspot could do something like that for example, not sure if it does.

I know, why do you think I was talking about tableswitch and lookupswitch? But just because there is bytecode for this, does not mean it was good to do so. Let me just name the JSR instruction as an example. It just looks good on the paper, that's all.

And when you say the slowest way... That is not valid fact unless you provide a testcase showing this. and the only thing I can imagine this could be important (and microbenchamrks do not count here) is a lexer as I already mentioned. But you would write a lexer in Groovy different from Java... for example you would have this in java:

case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9':

but this in Groovy:

case '0'..'9'

so you make one case statement where you had ten before. Let us do a little counting in GroovyLexer.java. I find

that makes 27 switch constructions with an average of 11 cases. Which means we are far away form hundreds of cases for a switch. And if I replace some of these with ranges, then I get an average of 4 cases for my switch. the really nasty cases with 87 and 64 cases can be replaced, so the maximum number is reduced to 30.

But all this is not really important... important is which construct is visited how often, and here I don't have numbers.

So... of course Groovy would gain much speed with such constructions in case of a lexer... that is if you write the Lexer in Java style. And I am not sure I would write the Lexer in the same style, even with using ranges as it is now if I had the abilities of Groovy. For example the Lexer uses BitSets, maybe I would use even more of them, then I get a massive reduction of the cases in many constructs. Maybe I would use a hash and closures instead at other places, then I get a big speedup again compared to a binary search. But certainly I would do something about that stupid NoViableAltForCharException, that costs so much performance in our.. ah, ok, thats the parser, not lexer ;)

I really think making our dynamic method calls faster is of a much higher priority than this. This doesn't mean we won't optimize this some time in the future, but atm there is no point in doing so.

bye blackdrag