The multipleDirs warning was added to avoid surprises related to where
windeployqt would deploy files when using binaries from different paths.
To do this properly, make the warning message more meaningful, and
suppress the warning when the --dir option is specified, i.e. when the
user is already explicitly choosing where to deploy.
Pick-to: 6.7 6.6
Change-Id: Ie2984f4af740776c568610370d49ad4ff85ffff0
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Unlike most of everything else in the Bootstrap lib, this is code that
couldn't be eliminated by the linker because they were referenced in one
static array. Maybe an exceptionally smart whole-program analysis could
do it, but GCC and Clang LTO modes don't do that now.
I removed the code that performed detection from HTML and from data too.
I could have left the detection of UTF-8 and "other" but this code
wasn't necessary. In particular, QTextStream couldn't benefit from it
because it already defaults to UTF-8, so the detection code would never
determine anything different from the input.
Drive-by removed QStringConverter::availableCodecs() too because it was
in the middle of functions #ifdef'ed out to.
This reduced the size of release-mode moc
text data bss dec hex filename
1079858 5440 640 1085938 1091f2 original/moc
1074386 5200 640 1080226 107ba2 updated/moc
-5472 -240 0 -5712 difference
Change-Id: I01ec3c774d9943adb903fffd17b7f114c42874ac
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
That is, use the inline functions that refer to <numeric_limits> and
<cmath> directly, instead of the out-of-line wrappers. Someone should
verify if the hacks for QNX's <math.h> are still required.
Change-Id: I01ec3c774d9943adb903fffd17b7ee560b4b71b9
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Bootstrapped tools don't usually need to list directories; they should
operate on file lists passed to it by the build system instead.
This may deserve a QT_FEATURE.
Change-Id: I01ec3c774d9943adb903fffd17b7ecfba2702fc5
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Just so we don't accidentally use different precisions. Amends commit
bfc7535a10.
Change-Id: I83dda2d36c904517b3c0fffd17b5258e88dd194e
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
They're all ported in one go because all the changes are the same and
they all rely on QTimerInfoList. The changes are:
- use Qt::TimerId to uniquely identify timer IDs
- use Duration (nanoseconds) to specify the timer interval
- rename registeredTimers() to timersForObject(), which is const
Change-Id: I83dda2d36c904517b3c0fffd17b52958767d8a68
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
No change in behavior, other than the ability for the precise timers to
be even more precise. There's a reduction in the stored interval range
from 292 million years to 292 years, but there's no change in behavior
because the timeout is stored as a steady_clock::time_point, which is
nanoseconds with libstdc++ and libc++. Now, if there's an overflow,
it'll happen on the call to registerTimer() instead of inside the
calculation of the wake-up.
Change-Id: I83dda2d36c904517b3c0fffd17b3d1f2d9505c1c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
This way, we can begin using the V2 methods now, regardless of whether
the concrete dispatcher class has been ported or not.
Change-Id: I83dda2d36c904517b3c0fffd17b52a6256b083af
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
This class is a temporary hack to enable transition to an API based on
std::chrono for the Qt event dispatcher. In Qt 7, it will be merged with
QAbstractEventDispatcher, replacing the pure virtuals there with the
ones defined here.
The new API differs from V1 in the following ways:
- uses Qt::TimerId instead of int to identify timer IDs, so we can't
accidentally confuse them with something else
- uses Duration (nanoseconds) to specify the interval, instead of a mix
of int and qint64
- add the missing const to remainingTime()
- rename registeredTimers() to timersForObject() (I'd have kept the
original name but we can't overload the name if the parameters are
exactly the same; we could have used QT6_DECL_NEW_OVERLOAD_TAIL, but
I think the new name is actually better)
Because the old API was mixing int and qint64, we didn't officially
support any timer for more than 2^31 ms (~24.85 days). This should
extend the valid range to 292 years once the dispatchers are ported
over.
Change-Id: I83dda2d36c904517b3c0fffd17b3a7e0afef4b59
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
That seems to be enough for me when trying to reverse-resolve host names
inside the corporate network.
Pick-to: 6.7
Change-Id: I6818d78a57394e37857bfffd17bc6b0ebd39f51b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Because QHostInfo is threaded, so if the look up times out and we exit a
given test, the results may still be delivered to the next test.
Especially if the next test is also about to time out -- in which case
it doesn't and prints a nonsensical output.
Before:
FAIL! : tst_QHostInfo::lookupIPv4(WithCache:literal_ip4) '!QTestEventLoop::instance().timeout()' returned FALSE. ()
Loc: [tst_qhostinfo.cpp(220)]
FAIL! : tst_QHostInfo::lookupIPv6(WithCache:aaaa-single) Compared values are not the same
Actual (tmp.join(' ').toLower()) : "192.0.2.1"
Expected (expected.join(' ').toLower()): "2001:db8::1"
Loc: [tst_qhostinfo.cpp(281)]
Now:
FAIL! : tst_QHostInfo::lookupIPv4(WithCache:literal_ip4) 'helper.waitForResults()' returned FALSE. ()
Loc: [tst_qhostinfo.cpp(278)]
PASS : tst_QHostInfo::lookupIPv6(WithCache:aaaa-single)
Pick-to: 6.7
Change-Id: I6818d78a57394e37857bfffd17bc66e241cab24d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This amends commit 205f8fbff0.
We silently supported the values c++14 and c++17 for the -c++std
argument. Support for both versions of the C++ standard was removed in
above mentioned commit.
Change-Id: I8f7dbc33f0a23164f712ac3d2e0a40bb8d12f225
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Replace public operators operator==() and operator!=() of QCborValue
to friend method comparesEqual().
Replace public operator<() of QCborValue to friend method
compareThreeWay().
Use QT_CORE_REMOVED_SINCE to get rid of current comparison methods
and replace them with a friend.
Delete #if 0 && __has_include(<compare>) blocks,
since they are not required anymore.
Task-number: QTBUG-120300
Change-Id: I884ff6ce2a71618b0e3eaa907f0852f93c2a073c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Make sure that plugin_init_target is not empty. It's empty when
creating qml plugins.
Amends 566b726b84
Pick-to: 6.7
Change-Id: If23998d50d8d31e20b3966730afb8b4b46b9990c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
QOperatingSystemVersion intentionally does not define operator==() and
operator!=() since ae072cd9c4.
It means that we cannot use comparison helper macros.
Still, we can manually define four relational operators or
operator<=>() in C++20 mode, and give the class a partial ordering.
We choose partial ordering, because versions of different OS types are
incomparable.
Implement the operators in terms of helper function compareThreeWay(),
which potentially allows to use this class in some templated code.
As a drive-by: make the static compare() function noexcept, because
it really is.
Fixes: QTBUG-120360
Change-Id: Id4c9ce740e42baa719ca0ee84146d087b21675c6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTypeRevision consists of two quint8 values: major and minor version.
Each of the versions can be unknown.
The rules for comparing with the unknown version are as follows:
zero version < unknown version < non-zero version
At the same time, two unknown versions are considered equal.
This makes the comparison a bit tricky, but it still fits into the
category of strong ordering.
Replace the existing friend relational operators with helper functions
and comparison helper macros, making this type strongly ordered.
Update the unit-tests to use the new comparison helper test functions.
As the test functions check the reversed arguments as well, we can
reduce the number of rows for the data-driven comparison test.
Fixes: QTBUG-120359
Change-Id: Ib6f1037fc7b5fed148e35ee48b56b05dcd36b3b4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This patch simplifies the checks when migrating the class to comparison
helper macros.
Task-number: QTBUG-120359
Change-Id: I47a6ba20d3b89c31edc2f432621eae9385fbd0a3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Done by harmonizing the use on the QT_CONFIG(temporaryfile) macro and
fixing one test that was missing. We can't remove the older macro
because it is marked PBULIC) but we don't need to use it ourselves.
Change-Id: I01ec3c774d9943adb903fffd17b7eb4dd1a4e63f
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
If the Android View is resized, the QWindow instantiated by it
should be resized accordingly.
Task-number: QTBUG-122626
Pick-to: 6.7
Change-Id: I7bfbca149f927718d1e28cdabfa8759afbd06039
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Qt window loading is initiated either when the QtView is attached
to its Android window, or when the Android QPA plugin has been loaded
and is ready, depending on the order. Since the window attachment
happens in the Android UI thread, and the Android QPA plugin callback
happens in Qt thread, add synchronized block to make sure the execution
stays ordered.
Fixes: QTBUG-122626
Pick-to: 6.7
Change-Id: Id476032f02aa8990432a02f62b6bf6237a17e7ac
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The SPDX database lists the license as 'Unicode-3.0', and 'Unicode
License v3'. Now, the SPDX standard actually says that
License identifiers (including license exception identifiers) used
in SPDX documents or source code files should be matched in a case-
insensitive manner.
But the website at https://spdx.org/licenses/ doesn't treat it this way,
so the link we generate out of the identifier actually gives a 404. So
it's just easier to use the 'original' capitalization.
Amends 063026cc50
Pick-to: 6.5 6.6 6.7
Change-Id: I826077a914721b7b9499ad62c08fdf20be94e88d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Some libs don't necessarily have the lib prefix in their names,
3rd party libs and Qt for Python might have that, so no need to
always add that prefix to loaded libs is the lib name already
contains a .so suffix.
Fixes: QTBUG-123286
Pick-to: 6.7 6.7.0
Change-Id: Ib65215d9b4410c5c9e00aa0642f48ab45c92fe03
Reviewed-by: Shyamnath Premnadh <Shyamnath.Premnadh@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
In the \fn commands for a limited number of methods in the
documentation for Testlib and Widgets, `= 0` is passed as default
argument instead of `= Qt::KeyboardModifiers()`. Until QDoc with Clang
17, inclusive, QDoc generated the correct signature. However, with
Clang 18, QDoc outputs `= 0` in the documentation. While strictly
speaking still correct, this change impacts the documentation
negatively in terms of readability.
Dropping the default argument from the \fn command ensures that QDoc
generates the right signature with both Clang 17 and Clang 18.
Task-number: QTBUG-123130
Pick-to: 6.7
Change-Id: I94ccec2f2c9a02241095fb5b18feb74aa55f97e1
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
We want to be able to pass as an argument whether the texture grabbed to
an FBO is supposed to have a flipped y-axis or not. This is required for
screen capture on the EGLFS platform.
Task-number: QTBUG-121835
Pick-to: 6.7 6.6 6.5
Change-Id: I6dddc879a4be7ff2c2c189747193423644be55a0
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
This is sensitive for the 'include' calls that expect cmake scripts
to be found in some staging prefixes. In yocto
QT_ADDITIONAL_PACKAGES_PREFIX_PATH points to the package image
path(installation snapshot). If repo provides bundled 3rdparties
the 'include' statement that includes 'FindWrap<3rdparty>ConfigExtra'
is unnable to locate it, since it's expected to be found in Qt
installation, but the file didn't land there at ptest stage.
Fixes: QTBUG-122205
Pick-to: 6.5 6.6 6.7
Change-Id: Idd03f44efd2e3fdaa476873068c73ac28cd0a7b5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We already have fine-grained macros to individually disable APIs
that we consider "suboptimal" or "dangerous". This commit adds
a shortcut for the user to set all such macros in one go.
QT_ENABLE_STRICT_MODE_UP_TO is versioned, just like
QT_DISABLE_DEPRECATED_UP_TO; the idea is that users should set it
to the minimum Qt version they want to support.
Also, if QT_DISABLE_DEPRECATED_UP_TO is not set, then
QT_ENABLE_STRICT_MODE_UP_TO will set it as well, to the same value.
[ChangeLog][QtCore][QtGlobal] Added the QT_ENABLE_STRICT_MODE_UP_TO
macro.
Change-Id: I5466465986104e047a6a86369928be9294f24ab7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Give it a name in line with the function name:
qAsConst -> QT_NO_QASCONST, as already done for qExchange.
We can do this because we never documented the macro itself.
So, while at it: also document the macro.
Change-Id: I6eb0834df438e4f4e818ef2cf8e702ed156dc253
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The EventPointMap QPointingDevicePrivate::activePoints is actually a
QVarLengthFlatMap<., ., 20>, not 16, so copy the value instead of just
hard-coding something.
Amends 296ede3aab.
Change-Id: Ic8e83f4095f57be74f7708d5cec6a19971772b76
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Before the qWaitFor() port from int to QDeadlineTimer, the
implementation constructed a QDeadlineTimer internally, passing int
timeout and Qt::PreciseTimer. The int overload that was retained for
source-compatibility, however, constructs the QDeadlineTimer without
the PreciseTimer flag, which is a behavior change.
Restore the Qt 6.6 behavior and pass Qt::PreciseTimer.
Amends fa296ee1dc.
Pick-to: 6.7 6.7.0
Change-Id: Ib8e5b912c74b70d32a77195edb0d2a30cd7c241d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Wrap dlerror() in QLatin1StringView(), like we already do in
unload_sys().
Amends a6a5681470.
Pick-to: 6.7
Change-Id: Ia8c91d6962c74d5916c47b2abbb3920f051c8e5e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use WebDriverManager to install the correct version of chromedriver.
This will help avoiding mismatch of Chrome/chromedriver versions,
which sometimes happen in CI.
Fixes: QTBUG-122729
Change-Id: I40cf62c02c2cb6f57b031cc83b9fa38f6ed2610e
Reviewed-by: Simo Fält <simo.falt@qt.io>
The bootstrapped tools really mustn't produce random output (they must
always be reproducible exactly). Therefore, ensure we don't need this
file.
Change-Id: I01ec3c774d9943adb903fffd17b7eb94dbd4be89
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
I added QT_NO_VARIANT to qconfig-bootstrapped.h to be clearer on what
the #ifs are, but there's no testing of that feature outside of
QT_BOOTSTRAPPED.
Change-Id: I01ec3c774d9943adb903fffd17b7e8ac4340fb89
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It was only used by the cmake_automoc_parser so it would write a 64-bit
in big-endian format. So bypass QDataStream and write it native
endianness.
Change-Id: I01ec3c774d9943adb903fffd17b79c78e56db4cf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Commit 90bc0ad41f ("QProcess/Unix: add
failChildProcessModifier()") added this line that set childStartedPipe
so that the failChildProcess() callback had something to write to. But
we left it set on exit from QProcessPrivate::startDetached(), which
caused the QProcess destructor to try and close it.
Noticed when debugging the issue for QTBUG-123083.
Pick-to: 6.7 6.7.0
Task-number: QTBUG-123083
Change-Id: I6818d78a57394e37857bfffd17bbc41c8400270f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Currently unused. I've tested that GCC 13 and Clang 17 do compile this
and do output reasonable assembly, with and without AVX512FP16 (I also
tested AVX10.1 with GCC 14).
Clang is unable to allocate a "v" (vector) register when T is qfloat16,
so I could only implement the conversion using _Float16. Strictly
speaking, Clang >= 16 always knows about _Float16, but I didn't want to
have a different detection from qtypes.h.
Change-Id: I6818d78a57394e37857bfffd17bae860f8055324
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The x86 SSE instructions do what we want and set a flag in the MXCSR to
indicate whether we should return false, so we can improve the codegen.
GCC generates for QStringView::toFloat():
call _ZNK11QStringView8toDoubleEPb
movl $8064, 12(%rsp)
movl $1, %eax
#APP
# 330 "/home/tjmaciei/src/qt/qt6/qtbase/src/corelib/global/qnumeric_p.h" 1
vldmxcsr 12(%rsp)
vcvtsd2ss %xmm0, %xmm0, %xmm0
vstmxcsr 12(%rsp)
# 0 "" 2
#NO_APP
movl 12(%rsp), %edx
testb $24, %dl
je .L2120
... handling of the under/overflow ...
The MXCSR instructions do need to read and write from memory, but the
stack is usually already in L1 and CPUs have special optimizations for
it.
There are two alternative implementations to the implementation chosen:
first, we could confirm there was no underflow or overflow using an
expression like:
(v == 0) == (*value == 0) && qt_is_finite(v) == qt_is_finite(*value);
But that is still very costly, with 4 UCOMISx instructions and several
memory loads.
Second, we could use the VFPCLASSSD and VFPCLASSSS (yes, 4 "S")
instructions to confirm whether a finite input became zero or non-
finite, but a) that's only available with AVX512, so of little practical
use today and b) it has a 3-cycle latency. Like the comparisons above,
we'd need 4 of them.
Change-Id: I01ec3c774d9943adb903fffd17b8b9cb2ce805ce
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
No change in behavior. But instead of trying to guess if we're going to
cross a page boundary, we check for the cacheline: if we don't cross a
cacheline boundary, then we can't cross a page boundary either. Testing
bit 4 can be implemented with a shorter instruction than a test for bit
11.
f43de: 40 f6 c7 20 test $0x20,%dil
Change-Id: I664b9f014ffc48cbb49bfffd17b04817a0fb8c6b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It's the same aeshash() as before, except we're passing a template
parameter to indicate whether to read half and then zero-extend the
data. That is, it will perform a conversion from Latin1 on the fly.
When running in zero-extending mode, the length parameters are actually
doubled (counting the number of UTF-16 code units) and we then divide
again by 2 when advancing.
The implementation should have the following performance
characteristics:
* QLatin1StringView now will be roughly half as fast as Qt 6.7
* QLatin1StringView now will be roughly as fast as QStringView
For the aeshash128() in default builds of QtCore (will use SSE4.1), the
long loop (32 characters or more) is:
QStringView QLatin1StringView
movdqu -0x20(%rax),%xmm4 | pmovzxbw -0x10(%rdx),%xmm2
movdqu -0x10(%rax),%xmm5 | pmovzxbw -0x8(%rdx),%xmm3
add $0x20,%rax | add $0x10,%rdx
pxor %xmm4,%xmm0 | pxor %xmm2,%xmm0
pxor %xmm5,%xmm1 | pxor %xmm3,%xmm1
aesenc %xmm0,%xmm0 aesenc %xmm0,%xmm0
aesenc %xmm1,%xmm1 aesenc %xmm1,%xmm1
aesenc %xmm0,%xmm0 aesenc %xmm0,%xmm0
aesenc %xmm1,%xmm1 aesenc %xmm1,%xmm1
The number of instructions is identical, but there are actually 2 more
uops per iteration. LLVM-MCA simulation shows this should execute in the
same number of cycles on older CPUs that do not have support for VAES
(see <https://analysis.godbolt.org/z/x95Mrfrf7>).
For the VAES version in aeshash256() and the AVX10 version in
aeshash256_256():
QStringView QLatin1StringView
vpxor -0x40(%rax),%ymm1,%ym | vpmovzxbw -0x20(%rax),%ymm3
vpxor -0x20(%rax),%ymm0,%ym | vpmovzxbw -0x10(%rax),%ymm2
add $0x40,%rax | add $0x20,%rax
| vpxor %ymm3,%ymm0,%ymm0
| vpxor %ymm2,%ymm1,%ymm1
vaesenc %ymm1,%ymm1,%ymm1 <
vaesenc %ymm0,%ymm0,%ymm0 vaesenc %ymm0,%ymm0,%ymm0
vaesenc %ymm1,%ymm1,%ymm1 vaesenc %ymm1,%ymm1,%ymm1
vaesenc %ymm0,%ymm0,%ymm0 vaesenc %ymm0,%ymm0,%ymm0
> vaesenc %ymm1,%ymm1,%ymm1
In this case, the increase in number of instructions matches the
increase in number of uops. The LLVM-MCA simulation says that the
QLatin1StringView version is faster at 11 cycles/iteration vs 14 cyc/it
(see <https://analysis.godbolt.org/z/1Gv1coz13>), but that can't be
right.
Measured performance of CPU cycles, on an Intel Core i9-7940X (Skylake,
no VAES support), normalized on the QString performance (QByteArray is
used as a stand-in for the performance in Qt 6.7):
aeshash | siphash
QByteArray QL1SV QString QByteArray QString
dictionary 94.5% 79.7% 100.0% 150.5%* 159.8%
paths-small 90.2% 93.2% 100.0% 202.8% 290.3%
uuids 81.8% 100.7% 100.0% 215.2% 350.7%
longstrings 42.5% 100.8% 100.0% 185.7% 353.2%
numbers 95.5% 77.9% 100.0% 155.3%* 164.5%
On an Intel Core i7-1165G7 (Tiger Lake, capable of VAES and AVX512VL):
aeshash | siphash
QByteArray QL1SV QString QByteArray QString
dictionary 90.0% 91.1% 100.0% 103.3%* 157.1%
paths-small 99.4% 104.8% 100.0% 237.5% 358.0%
uuids 88.5% 117.6% 100.0% 274.5% 461.7%
longstrings 57.4% 111.2% 100.0% 503.0% 974.3%
numbers 90.6% 89.7% 100.0% 98.7%* 149.9%
On an Intel 4th Generation Xeon Scalable Platinum (Sapphire Rapids, same
Golden Cove core as Alder Lake):
aeshash | siphash
QByteArray QL1SV QString QByteArray QString
dictionary 89.9% 102.1% 100.0% 158.1%* 172.7%
paths-small 78.0% 89.4% 100.0% 159.4% 258.0%
uuids 109.1% 107.9% 100.0% 279.0% 496.3%
longstrings 52.1% 112.4% 100.0% 564.4% 1078.3%
numbers 85.8% 98.9% 100.0% 152.6%* 190.4%
* dictionary contains very short entries (6 characters)
* paths-small contains strings of varying length, but very few over 32
* uuids-list contains fixed-length strings (38 characters)
* longstrings is the same but 304 characters
* numbers also a lot contains very short strings (1 to 6 chars)
What this shows:
* For short strings, the performance difference is negligible between
all three
* For longer strings, QLatin1StringView now costs between 7 and 17% more
than QString on the tested machines instead of up to ~50% less, except on
the older machine (where I think the main QString hashing is suffering
from memory bandwidth limitations)
* The AES hash implementation is anywhere from 1.6 to 11x faster than
Siphash
* Murmurhash (marked with asterisk) is much faster than Siphash, but it
only managed to beat the AES hash in one test
Change-Id: I664b9f014ffc48cbb49bfffd17b045c1811ac0ed
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
So that it hashes to the same value as QString{,View}.
In order to test this, you must either run on a CPU other than ARM and
x86, or disable the AES hasher. I did that and can confirm siphash and
murmurhash do work with on-the-fly conversion from Latin-1.
Change-Id: I664b9f014ffc48cbb49bfffd17b03e5e62ec4e89
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This complements the previous commit by adding the heterogeneous lookup
in operator[]. Unlike the members of the previous commit, this one may
insert into the hash, in which case it needs a way to cast from the
heterogeneous type K to the actual Key type.
Change-Id: I664b9f014ffc48cbb49bfffd17b037c1063dfb91
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>