[Development] Changing container privates again

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120609/4c904158/attachment.sig>