KDevVarLengthArray still required?

[Milian Wolff]

On Tuesday 12 January 2010 22:23:57 David Nolden wrote:
> Am Dienstag 12 Januar 2010 20:31:08 schrieb Milian Wolff:
> > Hey there!
> > 
> > Is our local modificated version of QVarLengthArray (i.e.
> > 
> >  KDevVarLengthArray) still required? I compared the sources with the one
> >  found in qt master (see [1]) and saw that the place marked as "this is
> >  the
> > 
> >  difference" changed a bit in Qt:
> > Our code:
> >         const int idx = s++;
> >         ///This is currently the difference to KDevVarLengthArray(which
> >  
> >  uses s == a), and it prevents a crash.
> >  
> >         if (s >= a)
> >         
> >             realloc(s, s<<1);
> > 
> > Their code:
> >         if (s == a)   // i.e. s != 0
> >         
> >             realloc(s, s<<1);
> >         
> >         const int idx = s++;
> > 
> > Esp. the reordering of the idx / s++ call could make the difference here.
> > I tried their code and ran a few unittests without any problems. Could
> > we
> > 
> >  ditch KDevVarLengthArray? It has a few extra Apis though:
> > removeOne, indexOf, insert, erase
> 
> Alone those APIs are reason enough to have a local copy, as they add quite
> a bit of convenience when working with KDevVarLengthArray, which is used
> in the duchain as a faster QVector replacement (it usually doesn't need a
> heap allocation). Also, the crash which was the reason why we forked it
> did not happen reproducably from what I remember, and I currently don't
> feel like doing further investigations on this, as we have enough
> significant issues to deal with.

Makes sense to me, thanks for the clarification.

> > All of them operate on the private ptr member...
> > 
> > On a different subject: an array (i.e. with consecutive memory blocks) is
> > 
> >  used to make writing/loading from disk faster, do I see that correctly?
> >  E.g. comment in appendedlist.h:
> >  
> >  * This file contains macros and classes that can be used to conveniently
> > 
> > implement classes that store the data of an arbitrary count
> > 
> >  * of additional lists within the same memory block directly behind the
> >  class data, in a way that one the whole data can be stored by one
> >  copy-operation * to another place, like needed in ItemRepository.
> > 
> > So I wonder: Is this really required? I mean now we suffer through the
> > 
> >  known pitfalls of such arrays: realloc, huge mem-blocks, ... I'd still
> >  like to see a Pool used here if possible, but I'm too much of a layman
> >  still I fear.
> 
> What this stuff does is maintaining a special data-structure that allows
> operating lists as KDevVarLengthArray when constructing them, but storing
> and using them as memory-pooled lists after they were stored to disk once,
> using the same API no matter whether it's currently stored in a pool on
> disk, or in a dynamic KDevVarLengthArray.
> 
> It makes loading faster (using a simple mmap), and at the same time it
> saves a lot of memory, as allocating every tiny list within the duchain
> separately leads to huge house-keeping costs in the heap manager.

OK, thanks.

> Actually I don't quite get the last sentence. You're contra huge
> mem-blocks, but pro memory-pools (aka huge mem-block)??

I thought mem-pools could use many blocks of a given size, i.e. exactly the 
difference? I mean malloc/realloc takes one sequential chunk of memory of 
requested size, no? And with a pool, when one needs more space, one can simple 
add a block and store the stuff there instead of realloc'ing all the existing 
stuff. Or am I mixing things up?
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100112/c7c05606/attachment.sig>