On Monday 17 October 2011 10:31:36 João Abecasis wrote: > On Oct 16, 2011, at 6:57 PM, ext Thiago Macieira wrote: > >> One thing I would like to add is the hash, for QString (and potentialy > >> QByteArray) > >> see: http://qt.gitorious.org/qt/qtbase/merge_requests/62 > > > > We discussed that but we're not satisfied that it will provide good > > results. It means spending 4 bytes to store the hash as well as > > hardcoding the hashing function until Qt 6. Someone mentioned that only > > 10% of the strings are ever hashed. In particular, I am not ready to > > give up a 16-byte alignment for the hashing. > > > > Maybe João can give more details of his thinking. > > 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.
QString's hashing is only part of the ABI because of the compile time hashes. Anyway, it can easily be versionized (read the comment on the merge request) that is, we add a uint stringVersion :8; in the flags, and qHash become if (stringData->hash && stringData->stringVersion == _Current_Version) return stringData->hash; //else ignore the embedded hash So this is not really an issue, is it? > Other concerns, as you mention, are the waste of space and whether the > resulting improvement is worth the trouble For the space, 16bytes is not much, just enough to store "QString" (in utf16 null-terminated) (at the same time, some people argue over QStringLitteral should be used instead of QLatin1String even in places where it does not matter from a performence point of view, while taking twice as much memory) > -- 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? Well, this is why QtDeclarative has its internal QHashedString. > I haven't given this much more thought, but I'm wondering if there are > places where introducing a QString-compatible QString-extension (say > QHashedString) would provide the same benefits... That is something that > can be played with before we change QString. The problem is that it is that the hash is lost each time we go back to a QString. -- Olivier P.S: This common pattern is problematic because there is no way to avoid computing twice the hash in the cache-miss case. (even if one could argue it is not a problem because cache-miss is meant to be a slow case) auto it = hash.find(key); if (it == hash.end()) it = hash.insert(key, computeValue(key)); return *it; _______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
