On Wed, Jun 13, 2012 at 06:14:59PM +0000, [email protected] 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' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
