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

[Gabriel Dos Reis]

Joris van der Hoeven <address@hidden> writes:

| >   "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)?

Yes.  They are implementation details I would strongly advise NOT
to explicilty depend on.  I think, it is much simpler/fair to just
mention that "if the labels are dense then the compiler would use a
branch table."   The various examples posted in this thread should
give a sense of what "dense" means.  

| By default, optimization is for speed, right (so 1/10)?

Yes.

| > | 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.

Agreed.  That is my conjecture.

[...]

| > | 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.

You're right, given some methodology.

Cheers,

-- Gaby