KDevVarLengthArray still required?

[David Nolden]

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.

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

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

Greetings, David