Some quick benchmarks against GNU coreutils 8.21 and OpenSSL 1.0.1e
(time in µs; time for coreutils and OpenSSL include the loading of the
executable):
Qt Coreutils OpenSSL
n SHA-1 SHA-224 SHA-512 SHA-1 SHA-224 SHA-512 SHA-1 SHA-224 SHA-512
0 0 0 0 717 716 700 2532 2553 2522
64k 120 484 381 927 1074 966 2618 2782 2694
Diff 120 484 381 210 358 266 86 229 172
The numbers for Qt are pretty stable and vary very little; the numbers
for the other two vary quite a bit, since they involve launching and
executing separate processes. We can take the lesson that we're in the
same ballpark for SHA-1 and we should investigate whether our SHA2
implementation is sufficiently optimized.
Change-Id: Ib081d002ed57c4f43741eca45ff5cd13b97b6276
Reviewed-by: Richard J. Moore <rich@kde.org>
According to my profiling of Qt Creator, qHash and the SHA-1 calculation
are the hottest spots remaining in QtCore. The current qHash function is
not really vectorizable. We could come up with a different algorithm
that is more SIMD-friendly, but since we have the CRC32 instruction that
can read 32- and 64-bit entities, we're set.
This commit also updates the benchmark for QHash and benchmarks both
the hashing function itself and the QHash class. The updated
benchmarks for the CRC32 on my machine shows that the hashing function
is *always* improved, but the hashing isn't always. In particular, the
current algorithm is better for the "numbers" case, for which the data
sample differs in very few bits. The new code is 33% slower for that
particular case.
On average, the improvement (including the "numbers" case) is:
compared to qHash only QHash
Qt 5.0 function 2.54x 1.06x
Qt 4.x function 4.34x 1.34x
Java function 2.71x 1.11x
Test machine: Sandybridge Core i7-2620M @ 2.66 GHz with turbo disabled
for the benchmarks
Change-Id: Ia80b98c0e20d785816f7a7f6ddf40b4b302c7297
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Changed the processing of non-character code handling in the UTF8 codec.
Non-character codes are now accepted in QStrings, QUrls and QJson strings.
Unit tests were adapted accordingly.
For more info about non-character codes,
see: http://www.unicode.org/versions/corrigendum9.html
[ChangeLog][QtCore][QUtf8]
UTF-8 now accepts non-character unicode points; these are not replaced
by the replacement character anymore
[ChangeLog][QtCore][QUrl]
QUrl now fully accepts non-character unicode points; they are encoded as
percent characters; they can also be pretty decoded
[ChangeLog][QtCore][QJson]
The Writer and the Parser now fully accept non-character unicode points.
Change-Id: I77cf4f0e6210741eac8082912a0b6118eced4f77
Task-number: QTBUG-33229
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove benchmark tests that are no longer required as they are simple
overloads of other methods.
Change-Id: I610211543d17c077f482fa2145ac3da7d0767282
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add support to QDateTime for time zones using the new QTimeZone class.
[ChangeLog][QtCore][QDateTime] Add support for a new Qt::TimeZone
spec to be used with QTimeZone to define times in a specific
time zone.
Change-Id: I21bfa52a8ba8989b55bb74e025d1f2b2b623b2a7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When calling intersect() on a large (1000000 items) QSet, with a small
(1000 items) QSet as the argument, the function takes signifcantly
longer than when the operand and the argument are reversed. This is
because the operand set is always iterated over in its entirety.
This patch changes intersect() to iterate over the smaller set. This
reduces the large operand scenario's benchmark to ~0.000063
milliseconds, compared to the current ~134 milliseconds:
1000000.intersect(1000) = empty: 0.000063 (was 134)
1000.intersect(1000000) = empty: 0.000039 (was 0.000036)
1000000.intersect(1000) = 500: 0.10 vs (was 130)
1000.intersect(1000000) = 500: 0.023 vs (was 0.093)
1000000.intersect(1000) = 1000: 0.20 vs (was 139)
1000.intersect(1000000) = 1000: 0.017 vs (was 0.016)
Task-number: QTBUG-22026
Change-Id: I54b25c49c78c458fef355e9c6222da8a64c7681f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It was only used for toUpper/toLower but always computed in the
constructor, including QString::toLatin1 conversion and allocations.
This needlessly slows down all other uses, including supposedly "cheap"
operations QString::toDouble, or accesses inside QResourceFileEngine.
The benchmarks indicates that doing it always when needed is bearable.
There's still a lot of improvement potential on these code paths.
Change-Id: I88b637ee11f9f7ea614f8da4ec5df0bf40664fce
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
In case somebody uses QVector as a stack, it is not fair to have
takeLast, removeLast and pop_back to do way too much work.
This is still very slow compared to std::vector::pop_back
(mostly due implicit sharing), however it is more than a
factor faster than before.
Change-Id: I636872675e80c8ca0c8ebc94b04f587a2dcd6d8d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This adds a fast insert on QMap when providing a correct hint.
Change-Id: I256bba342932c1d4f24c6e65074e1bf47b519537
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
The macro was made empty in ba3dc5f3b5
and is no longer necessary or used.
Discussed-on: http://lists.qt-project.org/pipermail/development/2013-January/009284.html
Change-Id: Id2bb2e2cabde059305d4af5f12593344ba30f001
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
These types are either built-in or 'automatically declared' and so
don't need to be explicitly declared as metatypes.
Change-Id: Iba4b7f8ff7a1c7974d144b955cbf064e43b36ec7
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
this is much more elegant than the so far propagated !isEmpty(QT.foo.name).
also replace feature-specific tests (no-gui and no-widgets) and the
obsolete contains(QT_CONFIG, foo) syntax.
Change-Id: Ia4b3c8febcabf9eeca67b1f9173a523820b1038b
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Reviewed-by: Tasuku Suzuki <stasuku@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
CONFIG += pcre is enabled if we're using the Qt PCRE, which isn't
compiled for 8-bit. If it isn't set, then we have a system PCRE.
Change-Id: I29d043b9d3f4d3223dcbb41eadc9f859e710eb88
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
it compiles just fine without it.
if this was meant to inject a newer version of JSC than what is in
QtScript, it can be redone without creating a bizarre hybrid.
Change-Id: I61fe60bfa6a9bdb6423e8a7135250e332a5835ec
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Also change Trolltech for QtProject in other places
Task-number: QTBUG-23269
Change-Id: Ie4e344f23cab77c575562d18b481b3369ce30491
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
We can insert directly on the most left-most Node.
We always enforce an insert here (unlike the insert call),
but that is not a problem since the keys in a std::map are unique.
Change-Id: Ib409b90ffc57a5a43dab4a4b08d34f6fdabd057f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
This suggestion keeps track of the most left node.
The point is that constBegin() becomes a lot faster.
That speeds up iteration a bit, and makes it O(1) to get the
first element. The penalty in insert and remove is very small.
On large trees it seems to be less than 1%.
It should be noticed that constBegin() is a very common hint
on my planned change to 5.1, and this opperation will without
this patch cost 2 x log N. One when the user calls the hint
with begin - and one where it is compared with begin.
Other std::maps has a very fast begin(). E.g
http://www.cplusplus.com/reference/stl/map/begin/
(begin with constant time)
Change-Id: I221f6755aa8bd16a5189771c5bc8ae56c8ee0fb4
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Giving the std-map a hint (normally) improves insert performance.
There seems to be no reason not to provide this hint.
Change-Id: I4344607ebf54574a3ae9666d87a41a3c14762361
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Qt 5.0 beta requires changing the default to the 5.0 API, disabling
the deprecated code. However, tests should test (and often do) the
compatibility API too, so turn it back on.
Task-number: QTBUG-25053
Change-Id: I8129c3ef3cb58541c95a32d083850d9e7f768927
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Change-Id: I19d3b2e9a5180b13deb828b55195404ef20be295
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
+ QChar::LastValidCodePoint enum value that supercede the UNICODE_LAST_CODEPOINT macro
replace uses of hardcoded values with the new API; remove leftovers
Change-Id: I1395c9840b85fcb6b08e241b131794a98773c952
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
0xfdef-0xfdd0 is definitely 31 and not 15 :)
also fix all copy-pastes of this code (greping for '0xfdd0' helps ;)
Change-Id: I8f3bd4fd9d85f9de066f0f5df378b9188c12bd48
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
Just like qMalloc/qRealloc/qFree, there is absolutely no reason to wrap these
functions just to avoid an include, except to pay for it with worse runtime
performance.
On OS X, on byte sizes from 50 up to 1000, calling memset directly is 28-15%
faster(!) than adding an additional call to qMemSet. The advantage on sizes
above that is unmeasurable.
For qMemCopy, the benefits are a little more modest: 16-7%.
Change-Id: I98aa92bb765aea0448e3f20af42a039b369af0b3
Reviewed-by: Giuseppe D'Angelo <dangelog@gmail.com>
Reviewed-by: John Brooks <john.brooks@dereferenced.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
QT_NO_STL is now no longer defined, so remove the conditionals and
select the STL side.
Change-Id: Ieedd248ae16e5a128b4ac287f850b3ebc8fb6181
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
QMap used to use a skiplist in Qt 4.x, which has variable
sized nodes and we can thus not optimise using custom
allocators.
The rewrite now uses a red-black tree, and all allocations
and tree operations happen in the cpp file. This will allow
us to introduce custom allocation schemes in later versions
of Qt.
Added some more tests and a benchmark. Memory consumption
of the new QMap implementation is pretty much the same as before.
Performance of insertion and lookup has increased by 10-30%. iteration
is slower, but still extremely fast and should not matter compared
to the work usually done when iterating.
Change-Id: I8796c0e4b207d01111e2ead7ae55afb464dd88f5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Changed benchmarks to use TESTDATA and QFINDTESTDATA
- Fixed up targets all use tst_bench_ syntax
Change-Id: I5c2936702e248478f5df225ce38893158ee22d7f
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
It's not faster under _any_ metric than the new algorithm, and it loses a lot of
spread which is a bad thing.
Change-Id: Ic87258f1c887822ffea1cb1517355564fabc3c26
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
We must do this the same way we do all other hash algorithms for fair
comparison, as otherwise, the call to the PLT unfairly penalises
QHash<QString>'s results, as it's in a different shared object.
Change-Id: I69c891f5a97dcccdfcfbdbf32796f86242a42963
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Per the comments on Ie4100a1ca4dbe7bf1cd73de883a9854377ac2f5e, having Q_ASSERT
was not a good idea, and data functions can't really handle
QVERIFY/QCOMPARE/etc, so do this in initTestCase instead.
Change-Id: I19e61dec7fe415bb1fa0f53a2920d99b8c7c8ea7
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Similar to the UUID benchmark, but won't have any non-numerical characters.
Change-Id: I7487c97cab96fd53c180fe12061e7be3ca96e883
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
This attempts to emulate a dictionary usecase of sorts, done in code to avoid
bloating the git repository by adding an actual word list.
Change-Id: I878bc4af8877ba780ee699932f240c0d9c8ff12c
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
remove "header" and assignmets which are defaults or bogus,
reorder some assignments.
Change-Id: I67403872168c890ca3b696753ceb01c605d19be7
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
The new layout matches that of QByteArrayData and QStringData, except
for offset which is measured from the beginning of QVectorData, whereas
in those classes it (still?) references the end of the header data.
The new layout uses an extra member for storing an offset into the data,
which will allow introducing QVector::fromRawData, similar to the same
functionality already existing in QString and QByteArray.
By not using an actual array to index array members, we also steer clear
of GCC bug #43247:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
Change-Id: I408915aacadf616b4633bbbf5cae1fc19e415087
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This includes padding necessary to align the data array, but excludes the first
element as was done before. Size of header is the interesting piece of
information, anyway.
This simplifies calculations in a couple of places, harmonizes code with the
QRawVector fork and paves the way for further changes in QVector, namely the
memory layout.
When Q_ALIGNOF is not available, default to pointer-size alignment. This
should be honoured by malloc and won't trigger use of more expensive
aligned allocation.
Change-Id: I504022ac7595f69089cafd96e47a91b874d5771e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For non-movable types (QTypeInfo<T>::isStatic), QVector would grow the
array linearly, and defer to qAllocMore otherwise. That property,
however, gives no indication as to how the vector will grow.
By forcing additional allocations for growing containers of such types,
this penalized exactly those objects which are more expensive to move.
We now let qAllocMore reign in growth decisions.
Change-Id: I843a89dcdc21d09868c6b62a846a7e1e4548e399
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
UUIDs are a good testcase, because the textual content is all fairly similar.
This also changes data generation to be a little neater now that we're starting
to get multiple pieces of data.
Change-Id: Ie4100a1ca4dbe7bf1cd73de883a9854377ac2f5e
Reviewed-by: Giuseppe D'Angelo <dangelog@gmail.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
