> (4x difference measured). wow, good to know.
------- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Oct 10, 2017 at 3:33 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: > On Tuesday, 10 October 2017 15:04:29 CEST Jean-Michaël Celerier wrote: > > > ** Wrapping std::{unordered_}map may be acceptable > > > > Hmmm... from these benchmarks, QHash seems to regularly beat > > std::unordered_map so is it really worth it ? > > => https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html > > The motivation for change is not performance, but security. While we don't > think Qt applications are particularly susceptive to HashDoS attacks, our > approach here is "we can fix this, we may as well do it". > > The reason I'm benchmarking and suggesting SipHash-1-2 instead of the > standard > SipHash-2-4 is to avoid a big performance regression. > > > Besides, with the Qt implementation the performance is more-or-less > > consistent across platforms ; if it were to use > > std containers with moderately advanced algorithms, there could be much > > more differences depending on the various implementations > > (the worse offender being std::regex... these damn things just don't work > > the same on any platform). > > We actually have VERY different performance numbers across platforms. QHash > currently uses the CRC32 instructions on x86 and ARM, which means the > peformance can change significantly (4x difference measured). The same > applies > to the fixed version: the AES instructions are 5x faster than SipHash. > > > More generally, since all these containers are header-only due to their > > templated nature, wouldn't it be interesting and benefiting to the > greater > > C++ community to > > spin them off in their own small header-only utility library ? > > That's one big concern for a Qt6 QHash that wraps std:unordered_map. We'll > need to see what happens. > > > Having an explicit choice between COW and no-COW would be valuable in > many > > places where people don't want to bring large stuff like whole QtCore but > > where a few headers are OK imho; > > offering facades to std:: types with easy, readable Qt-like APIs would > also > > be quite nice (ideally with a set of standard-compliant typedefs, eg > > qt::hash_map... one can dream :p). > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
