[Kde-bindings] branches/work/kdebindings-smoke2

[Richard Dale]

On Thursday 19 July 2007, Arno Rehn wrote:
> Am Donnerstag, 19. Juli 2007 schrieb Arno Rehn:
> > SVN commit 689711 by arnorehn:
> >
> > * First steps to implement Richard's proposal of a global
> >   "class name => smoke module" map.
>
> Uhm, I just thought about that again. I would be possible, yes. But I think
> a major slowdown would come together with that change. Just imagine that
> cast function, it's currently based only on very fast switch statements.
> With a class name => smoke module map we'd have to do many strcmp() calls
> here to check what class we want to cast to.
We don't have to remove all references to classes which aren't in the current 
module. For classes inside the current module we need the x_* classes and 
tables to look up the methods in them. The classes outside the module just 
given class ids and marked as 'external' (or hasFire() returns false). 

For the casting table we need all the parent classes, even if they are not in 
the current module. For types, we need a table of all types used by the 
current module even if they weren't defined in the module's classes.

> For the type array we'd also have to implement such a map, which would
> possibly double or triple the memory consumption. Then is the access to the
> smoke instance via Indexes faster than with map::find(), as far as I know.
> Still I think it's quite a good idea to have quick access to the smoke
> instances via the class name in a global map, so the current state could be
> kept. But performance will suffer if we completely drop the Index thing
> from Smoke, in my opinion.
We need to measure how much memory the various tables use - it might be small 
compared with the size of the x_* classes. Being able to split up the libs 
and only use the ones we want, should mean we actually end up using less 
memory. We cache method selectors once we've looked them up once, and so the 
overhead of looking them up in multiple smoke modules might not be as bad as 
it seems.

I think it's better to get something working and measure it, than think that 
something might be slow in advance without measuring.

-- Richard