On sábado, 9 de junho de 2012 21.42.55, André Pönitz wrote: > My gut feeling says there is a sweet spot at 16 byte object size, > with direct pointer to the raw data, and size member and some > sensible use of the extra bits.
Agreed, but it's 16 bytes on 64-bit architectures. On 32-bit ones, it would
have to be 8 or 12, preferably the smaller one (i.e., keep it to two
registers).
> Whether this is needed, or whether the "cheap substrings" are a
> sufficient replacement for the cases where QStringRef currently
> is actively used, and what the actual impact is something that
> I don't know. "Spending a thought or two" doesn't seem to hurt,
> though.
Cheap substrings can be achieved with from fromRawData provided we also move
the size into the main class. That's relatively easy to do (compared to the
full proposal), but even this change might not be doable in the time frame we
have.
What's more, those cheap substrings, if they are still QStrings, they pose two
problems: since they become indistinguishable from regular, users may "leak"
them past the lifetime of the original string, and the zero termination will
not be present.
Also, I'm extremely against an encoded anything in order to save bits. Using
sign bits and other hacks will possibly bite us in our backs because it makes
other things slower.
If I had enough time to redesign, I think I'd start with:
class QVector / QByteArray / QString
{
Data *d;
uint flags;
int size;
};
struct Data
{
qptrdiff offset;
};
struct AllocatedData : public Data
{
QRefCount ref;
int alloc;
};
The unsharable and immutable types would be in the flags member in the main
class. This way, QStringLiterals and other literals would have a 4-byte
overhead.
Right now, before doing a refcount up or down, we already need to fetch the
value and verify if it's not one of the non-counted types (btw, it does two
comparisons instead of one). So checking the flags in the main object's body
would be no worse.
A drawback on this design is that both types of data produce misalignments,
but that's fixable by wasting some more bytes.
It's either this design or the one with the flags in the private, which would
produce a 8 or 16-byte private.
--
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
