[Development] Changing container privates again

[João Abecasis]

Thiago Macieira wrote:
> On segunda-feira, 11 de junho de 2012 16.00.58, João Abecasis wrote:
>> Thiago Macieira wrote:
>>>> Following Olivier's suggestion I think it might be beneficial to have
>>>> alloc
>>>> unconditionally in the base class, even if it is not being used at times.
>>>> If nothing else, it saves padding. Additionally, deleter function and
>>>> token
>>>> would be more generally useful if they can be used with the alloc member.
>>> 
>>> Yes, if we move the alloc member to the main struct, then it will simply
>>> occupy the space currently used for padding. The total overhead for an
>>> allocation would be 24 bytes on 64-bit systems. Since glibc's allocator is
>>> 16- byte aligned, this means our data is always 8 bytes off.
>>> 
>>> In my opinion, that's actually worse than having a larger header.
>> 
>> But that's what we currently have and wouldn't change with you suggestion
>> above, right?
> 
> We currently have 24 bytes. With my changes, it goes to 32 bytes, which is the 
> second most ideal value. The ideal one would be 16 bytes.

The proposed QArrayAllocatedData is 32-bytes in size, but at the cost of two 4-byte padding holes. That's not that much different from a 24-byte header with no holes -- you can always add padding at the end ;-)

With a 32-byte default header you get the prepend optimization for free:

    struct QArrayData
    {
        qptrdiff offset;
        uint size;

        QtPrivate::RefCount ref;
        uint flags;

        uint alloc;
        qptrdiff beginOffset;
    };

24/32 bytes. (16/24 bytes if we move offset and size out)

Did you mean something else?

>> Would it be worth to set the minimum alignment for the data as 16-bytes, at
>> the expense of padding we explicitly add in QArrayData::allocate? (Since
>> this decision can be done inside that function it would have no impact on
>> ABI)
> 
> QArrayData::allocate can take that decision. In fact, that was in my plans for 
> some future improvement.
> 
> But that means we'll use 32 bytes anyway for all allocations, in any platform.

The decision can still be made conditional on the architecture or so.


João