On Monday, 17 de October de 2011 10:31:36 João Abecasis wrote: > When we discussed this, no one seemed to be much in favor of the change, in > subjective terms. One concrete show-stopper is the concern that it makes > QString's hashing function part of the ABI.
That's the worst part IMO -- assuming that the patch to calculate hashes at
compile time (C++11 feature) goes in too.
> Other concerns, as you mention, are the waste of space and whether the
> resulting improvement is worth the trouble -- so, 10% of strings are ever
> hashed, but are there places where we re-hash the same string over and over
> that other improvements in code would provide better results?
If we give up on the 16-byte header, then we may have room for storing a hash.
E.g.:
QAtomicInt ref;
int alloc;
qptrdiff begin;
qptrdiff end;
int flags;
int hash;
// size = 24 (32) bytes
We could even use a bit in the flags to indicate which version of the hashing
function was used, if we choose to change it later. That means hashing at
runtime all the constant strings that haven't been recompiled -- a solution
that is no worse than the current solution.
In theory, a compile-time hash could even use the reference counter field, as
long as it produces a negative number.
--
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
