On Sunday, 16 de October de 2011 17:02:10 Olivier Goffart wrote: > On Sunday 16 October 2011 16:30:39 Thiago Macieira wrote: > > When I talked to João this week, he expressed the desire to unify the > > header code of QVector, QByteArray and QString. Since QByteArray is a > > vector of char and QString is a vector of QChar / ushort, it makes sense > > to unify the code to simplify maintenance. Whether specific optimisations > > in allocation policies are needed, we can figure out later. > > Appart from consistency in out internal structures, what is the gain? > What is the code that can be reuse? (Appart the declaration itself, i can't > think of any) > > As this is an internal thing, this do not give us anything regarding the API > point of view. > And this keep us to have nice per/data structure optimisation. > > In other word, i'm not really in favor of this.
Why? The gains are the simplification and the limited code reuse. And as you say, it's an internal thing. What reasons are there not to do this? We'll have three classes with the exact same members anyway... > (I think the sharing should happen at code level, by providing the same > interface which enable templated code (like QStringBuilder) to work of all > types.) Sorry, I didn't get this part. What do you mean by it? > > QAtomicint ref; > > int size; > > int alloc; > > qptrdiff offset; > > // size = 16 (24) bytes, alignment = 4 (8) bytes > > > > Note how there's a 4-byte padding gap before the "offset" member on 64-bit > > platforms and how the data starts at an offset of 24 bytes. Given a > > 16-byte > > aligned allocator, which is common on 64-bit platforms, the data starts at > > an 8 byte offset from the nearest 16-byte alignment, which is a problem > > for > > SSE2 optimisations. > > One thing I would like to add is the hash, for QString (and potentialy > QByteArray) > see: http://qt.gitorious.org/qt/qtbase/merge_requests/62 We discussed that but we're not satisfied that it will provide good results. It means spending 4 bytes to store the hash as well as hardcoding the hashing function until Qt 6. Someone mentioned that only 10% of the strings are ever hashed. In particular, I am not ready to give up a 16-byte alignment for the hashing. Maybe João can give more details of his thinking. > > I'd like to pick all of your brains for a solution that has the following > > > > properties: > > - size always 16 bytes > > Not possible on 64bit > Or did you mean "multiple of"? No, I meant 16 bytes exactly. I think it's possible, so I'll disregard your "not possible" part. If we can't make it fit 16 bytes, then we have a question to be asked: is 24 good enough or should we go for 32? 32 bytes gives us our 16-byte alignment *provided* that the allocator is also doing that. But if we have fromRawData, we'll need to support misaligned operations anyway. > > - contains a qptrdiff offset, to still allow for fromRawData (which we'd > > then introduce to QVector too, but not QList) > > And there again you are saying it will be different for QList and QVector > Or you want to put a lot of unions there (which negates the hole purpose) QList<T> where T is a small movable type is a wrapper or typedef around QVector<T>. QVector has the fromRawData option, whereas QList doesn't. > > - can store at least one 1-bit flag, but 2 would be preferred > > The more flag you have, the more future proof you are if you want to keep > binary compatibility. > > > - size calculation reasonably fast > > And add stuff like: > - can be generate at compile time and put in the .rodata (like we did for > QString) That implies having no pointers, which is why QString has that qptrdiff offset in the first place. QVectorData and QListData today already don't have any pointers. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
