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

[Joris van der Hoeven]

>   "Density" in the current GCC implementation is expressed as a ratio
> of number of labels over the range of the cases.  For example if you're
> requesting optimization for size, then it might be that the switch is
> dense if that ratio is greater than 1/3, otherwise it might be 1/10.

Are you sure about these numbers (1/3 and 1/10)?
By default, optimization is for speed, right (so 1/10)?

> | I hope so! Maybe that you have to give the user some control
> | over the optimization. If the code is optimized for small size,
>
>    Well, a big concern with GCC is that it already has far too many
> options, and not all combinations of them are fully tested.  Anytime a
> new option is added (at user level), it implies a new combinatorial
> complexity.  So, there is some resistance to put options about any
> single decision made by the compiler...

Well, optimization over size/speed should already provide some control.

> |   2) A table with 200 items is not that large in memory for
> |      present standards.
>
>   Well, it is not clear off hand that even when you're optimizing for
> speed a branch table of size 200 with only 5 relevant entries will be
> faster, compared to a series of less than five compares.  It depends
> on other factors like the costs of instructions or the cache lines,
> or... all other low-level details you usually don't care about.

Yes, but I am thinking about branch tables of size 150
with between 10 and 30 relevant entries... :^)

> | Finally, I think that if you switch over an enum,
> | then the likelyness of table lookup should be increased.
>
>   I don't know.  I don't believe it makes any difference with C enums.
> C++ enums are a bit different, since the C++ standard allows for short
> ranges -- and g++ does take advantages of that in some minor cases.

Enums (without explicit numbers for the items) are by default dense,
and they usually serve a dense purpose. So there should be a bonus
with regards to the required density rate.

> I don't know if Texmacs has routines to report on time it spends in
> various parts...

Not really; I can easily add such routines for clearly identified tasks.
But if I want to optimize typesetting efficiency, with hundreds of
subroutines, then I have to use tools like gperf. I spent a few days
doing that in the past, but this is a heavy operation.