Optimization of switch statements?

[Kristian Waagan <Kr...@Sun.COM>]

Hello,

While looking through some code related to data types, I came across a 
few switch statements. I know these used to be optimized "in the old 
times", typically in two ways:
 o Keep the values close to each other (to enable use of a direct lookup 
table).
 o Put the most frequently seen values up front.

Does anyone know if such optimizations still have any meaning?
Or are the hotspot optimizers smart enough to do something about this now?

This question is more about curiosity than hope of any significant 
speed-ups :)
And no, I haven't written a micro benchmark for this...


-- 
Kristian

Re: Optimization of switch statements?

[Knut Anders Hatlen <Kn...@Sun.COM>]

Kristian Waagan <Kr...@Sun.COM> writes:

> Hello,
>
> While looking through some code related to data types, I came across a
> few switch statements. I know these used to be optimized "in the old
> times", typically in two ways:
> o Keep the values close to each other (to enable use of a direct
> lookup table).
> o Put the most frequently seen values up front.
>
> Does anyone know if such optimizations still have any meaning?
> Or are the hotspot optimizers smart enough to do something about this now?
>
> This question is more about curiosity than hope of any significant
> speed-ups :)
> And no, I haven't written a micro benchmark for this...

Hi Kristian,

I don't know for sure that the runtime compiler is smart enough to
optimize it, but I was under the impression that it collected statistics
before optimizing the code, and reordered statements based on the
statistics. Switch statements do sound like a likely candidate for such
a reordering, at least when a lookup table cannot be used, so my guess
is that putting the most frequently seen values up front won't affect
the performance. It might have other positive effects, though, like
making the code clearer by telling the reader what's expected to be the
most common case.

I would expect keeping the values close to each other in order to make
the table-driven approach applicable would give slightly better
performance if the code is called frequently and has many cases. For
switch statements with a smaller number of cases, I wouldn't expect any
difference at all. This reminds me of a blog I read a while ago, about
the potential negative impact of forcing a table-driven switch:

http://weblogs.java.net/blog/sdo/archive/2007/07/switching_track.html

-- 
Knut Anders