Re: [Texmacs-dev] Efficiency of C++ switch-statements

[Joris van der Hoeven]

Hi,

Thanks for your detailed reply.

On 11 Nov 2003, Gabriel Dos Reis wrote:
>   As far as GCC/g++ is conerned, g++ shares the same middle-end and
> back-end as the C front-rend (and Fortran and other supported
> languages). Here is what the GCC source says (gcc/stmt.c):
>
>    Switch statements can be output in one of two forms.  A branch table
>    is used if there are more than a few labels and the labels are  dense
>    within the range between the smallest and largest case value.  If a
>    branch table is used, no further manipulations are done with the case
>    node chain.

This is a bit vague: what is dense? 25% full? 50% full? 99% full?

> This is to be taken with a grain of salt.  This may change in the
> future as the compiler is improving and more optimizations are being
> implemented (e.g. tree-ssa branch).

I hope so! Maybe that you have to give the user some control
over the optimization. If the code is optimized for small size,
then a binary branch table (small tables) and an automatically
generated hash table (big tables) would probably be best.
If the code is optimized for speed, then a 10% full table
should still be considered as dense in my opinion.
Don't forget that
  1) The number of large switch statements (more than 10 items)
     is usually not that large: they happen at strategic dispatching
     points in the code.
  2) A table with 200 items is not that large in memory for
     present standards.
Finally, I think that if you switch over an enum,
then the likelyness of table lookup should be increased.

> | Another question: if I do not put the cases in the same order
> | as the enumeration, does this alter the efficiency?
>
>   Not, as far as GCC is concerned, see the comment above.

OK, so you are sure that I don't need to worry about occasional
permutations of cases?

> And what appears inefficient today may be very efficient tomorrow given
> that the compiler is rapidly improving.  My rule of thumb in this are is:
> design the algroithm, code, measure, optimize.

The point is that measuring/optimizing is harder for a program
like TeXmacs than for, say, a mathematical library.

Best wishes, Joris