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.
> 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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
