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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
