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

[Arno Rehn]

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

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

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


-- 
Arno Rehn
arno at arnorehn.de