kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Jun 09, 2014 at 08:55:57AM -0500, Dick Hollenbeck wrote:
> On that good day the switch() code generater will use a jump table with machine code which
> could also come from this type of construct:
> 
> (*jump_table[switch_enum - switch_lowest_value])()

On other *very* good days the compiler snuff out the ifs and do a jump
table (seems incredible but it does...). However even the venerable
borland 2 compiler did the range optimization you said.

> If gaps in the enum are not overwhelming, then those will get filled with jumps to
> "default:".  The main point is that if this is in a drawing loop, then it becomes a
> hotspot.  Not having multiple else if tests makes it very lean.  There are no tests, only
> one indexed lookup.

You could force that path with a lookup table to functions, indexed by
the type. Usually the compiler is smart enough to recognize it anyway
(except fujitsu ones, where I had to do the table trick)

> We moved PAINTER out of the object hierarchy for good reasons.

Otherwise it would been have simply a call to [VTBL+offset]. Breaks all the
OO advantages but I presume the reasons where good. Also I don't
particularly care about OO practices, unless the gain is obvious or
forced by management. To run a stock reports we still use COBOL, and
there is a reason for that:P

> Unless you can match the kind of performance that a large switch() provides, I think this
> ClassOf is not a good path to entertain.

I wasn't thinking particularly about the painter logic; it seemed to me
a somewhat convolved way to do a simple thing. However it seems that in
'modern' C++ you always have to do convolved things for simple tasks...

> Nor does it fix anything.

It's faster than dynamic_cast (certainly, since it's not solving the
generic IS-A problem) and *maybe* slightly more convenient than
an 'if (type ==) static_cast'.

Anyway: I don't thing that would be such an hotspot in the paint code,
relatively talking.  Just sum out all the math needed for building the
opengl points and stuff and you'll see probably the cost for dispatching
on the kind of object is swamped by the actual painting work.

IMHO the switch would be the most simple way to do the dispatch (until
proven otherwise, the KISS principle rules). Further profiling could
show the actual hotspots (either gprof or valgrind).

-- 
Lorenzo Marcantonio
Logos Srl