[Development] QStringRef conversion functions

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Wed Jun 13 22:28:17 CEST 2012


On Wed, Jun 13, 2012 at 06:14:59PM +0000, aaron.kennedy at nokia.com wrote:
> > That is what I'd love to see in 5.0.  Making sub-QStrings as cheap
> > as QStringRef currently is would give us quite significant
> > performance boost in some common use-cases. Then, QStringRef
> > definitely should go.
> 
> Won't a QString always require an allocation for the d-ptr?  So it'll
> never be quite as cheap as QStringRef.

Depends on the implementation.

One suggestion was to store "enough" data inside the object proper to
not require "external" data fields for those cases. The amount of data
needed depends on the operations one wants to support. As far as I can
see, two pointers + one int (one direct pointer to char data, one
pointer to auxillary data like refcount, flags, alloc, one int for size)
are enough for "everything" including fast direct accesse to the
character array and size. But that's fat (20 byte on 64bit, 12 on 32).
Too fat even. 16/8 would be _much_ better.

If someone came up with a clever idea to _safely_ replace the auxiliary
pointer by a 32 bit offset to the data pointer there is even some hope
for a _really_ good solution, at least for 64 bit....

Andre'



More information about the Development mailing list