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

Richard Dale rdale at foton.es
Fri Jul 20 13:29:14 UTC 2007


On Friday 20 July 2007, Arno Rehn wrote:
> Am Freitag, 20. Juli 2007 schrieb 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).
>
> You mean we should add the classes which aren't in the current module, but
> in some way needed, to the classes table, just marking them "external" ?
Yes

> > 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.
>
> Yes, that's current state. What I think of is the follwing:
> In the cast funtion, we currently find out what class to cast to like this:
>
> static void *qsci_cast(void *xptr, Smoke::Index from, Smoke::ParentIndex
> to) { switch(from) {
>       case 1:	//QsciAPIs
> 	switch(to.parent) {
> 	  case 1:	// in SmokeQt
> 	    switch(to.index) {
> 	      case 267: return (void*)(QObject*)(QsciAPIs*)xptr;
> 	      default: return xptr;
> 	    }
> 	  case 0:	// in current module
> 	    switch(to.index) {
> 	      case 1: return (void*)(QsciAPIs*)(QsciAPIs*)xptr;
> 	      default: return xptr;
> 	    }
> 	  default: return xptr;
> 	}
> [...]
> }
>
> If we drop the parent modules table, we won't be able to nicely switch()
> through them.
I think this table should be exactly the same as for smoke v1. As long as we 
have class ids for classes that are not in the current module, but that are 
parent classes of classes which are in the current module.

> > > 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.
>
> As there are _way_ more types than classes for each module, so I think it's
> quite likely that memory consumption would easily triple (SmokeQt: 520
> classes, 1900 types). I measured the difference with 549 classes (SmokeQt +
> SmokeQScintilla). With that map we allocate around 448K, without 421K. So
> the additional map uses around 27K. If we set up a type map, we easily add
> another 94K +.
> I don't think it' that much of a problem, though. Recent computers don't
> ship with only 128M of RAM anymore.
>
> > 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.
>
> Performance might not suffer as badly as I first thought, but memory
> consumption will surely increase, I think.
Yes, but from your figures above it doesn't sound too bad.

-- Richard




More information about the Kde-bindings mailing list