Have one generic method for detaching and reallocations.
Use that method throughout QList to avoid duplicated
instantiations of code paths that are rarely used.
Change-Id: I5b9add3be5f17b387e2d34028b72c8f52db68444
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Emplace() implemented with std::rotate is just awful on my system
(Ubuntu 18.04 GCC 7.5.0). Custom code is much faster, so go for
it. Cannot really use insert() code, which is also fast, because
it doesn't forward-reference values but copies them always
Changes in performance (approximately) for emplacing 100k elements
into the middle:
Complex 7600ms -> 1700ms
Movable 7600ms -> 200ms
Task-number: QTBUG-86583
Change-Id: If883c9b8498a89e757f3806aea11f8fd3aa3c709
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use GrowsAt* and GrowthPosition as that is clearer.
Change-Id: I3c173797dec3620f508156efc0c51b4d2cd3e142
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Inline them into the one place they are called from
and remove duplicated code.
Change-Id: Ica88485e98625905083b16c24ee9eaf223a89ae0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Get rid of the allocation options inside the flags
field of QArrayData, they are really a completely
separate thing.
Change-Id: I823750ab9e4ca85642a0bd0e471ee79c9cde43fb
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Don't use QArrayData::GrowsForward/Backward anymore and replace
it with a simple 'bool grow'.
Change-Id: Ifddfef3ae860b11dda4c40854c71ef2aeb29df34
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
reallocate() should only ever call realloc(), and only be used to
create more space at the end of the data.
Change-Id: I2ac4dbc90d2afaa571bb620108d7984356712cb2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
The while insertion logic will need further work to make it
more efficient. Currently it does use copy construction and
assignment for internal moving instead of move operations.
Change-Id: I7ae3094daa43a44629d8fa89ab6562c2a21b6cbd
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Avoid moving data inside the array to create free
space at one end. This is a performance bottleneck,
as it required quite a lot of calculations for every
insert. Rather reallocate and grow in this case,
so we only need to do expensive work when we reallocate
the array.
Change-Id: Ifc955fbcf9967c3b66aa2600e0627aac15f0c917
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
It looks like we can drastically simplify the way QADP grows without
sacrificing much:
1. append-only use cases should have the same performance as before
2. prepend-only use cases should (with the help of other commits) get
additional performance speedup
3. mid-insertion is harder to reason about, but it is either unchanged
or benefits a bit as there's some free space at both ends now
4. mixed prepend/append cases are weird and would keep excess free
space around but this is less critical and overall less used AFAIK
Now, QList would actually start to feel like a double-ended container
instead of "it's QVector but with faster prepend". This commit should
help close the performance gap between 6.0 and 5.15 as well
As a drawback, we will most likely have more space allocated in mixed
and mid-insert cases. This needs to be checked
Task-number: QTBUG-86583
Change-Id: I7c6ede896144920fe01862b9fe789c8fdfc11f80
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change types returned and accepted by capacity-related QArrayDataPointer
functions to qsizetype:
1) QArrayData (underlying d-ptr) works with qsizetype
2) QArrayDataPointer::size is of type qsizetype
3) All higher level classes that use QADP (e.g. containers)
cast capacity to qsizetype in their methods
Additionally, fixed newly appeared warnings through qtbase
Change-Id: I899408decfbf2ce9d527be7e8b7f6382875148fc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To match QString and QByteArray behavior
Change-Id: Ifce4a5dee6fc9077e855a24499f11f911e359cf5
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Updated moveNonPod function to behave correctly under
exceptions being thrown. This is the version that was implemented
at some point but then got changed prior to merge. Added tests for
moveInGrowthDirection (which uses moveNonPod in general case) to
verify that range movements are correctly done
Updated QCommonArrayOps access modifier from private to protected
to allow testing of internal stuff by subclassing
Task-number: QTBUG-84320
Change-Id: Idb994a72ee601762e32248670cdc7819aaca0088
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Scoped GrowsBackwards-optimized erase to only be applied
when erase starts at the beginning of the element range.
In other cases, old "left-shifting" erase is used to align
with std::vector::erase invalidation policy
Task-number: QTBUG-84320
Change-Id: I2e7f3b96b056bc371119eb2d36cc7c74af52c394
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Introduced prepend optimization logic to QCommonArrayOps.
Trying to rely on original QList behavior
Task-number: QTBUG-84320
Change-Id: I46e6797b4edad804a3e3edb58307c9e96990fe01
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Introduced allocation function in QArrayDataPointer with
interface similar to QArrayData::allocate that supports growing
strategies. This func is used instead of the original in cases
when prepend-aware storage is needed. Tried to follow Qt5 QList
policy in terms of space reservation
Updated QPodArrayOps::reallocate to be aware of growing
shenanigans. It doesn't look like a perfect solution but it is
rather close and similar to what Qt6 QList is doing when not
growing (e.g. reserve/squeeze)
Added initial QCommonArrayOps with helper function that tells
when reallocation is preferable over just using the insert-like
operation. This comes up later on when GrowsBackwards policy is
properly supported in operations
Essentially, 2/3 main data management blocks for prepend optimization
are introduced here. The last one being a generalized data move that
is done instead of reallocation when existing free space is not enough
Task-number: QTBUG-84320
Change-Id: I9a2bac62ad600613a6d7c5348325e0e54aadb73d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove QTypeInfo::isStatic, as that's not used anymore in Qt 6.
Also remove sizeOf, it's unused, and we have QMetaType for that if
required.
Remove all typeinfo declaractions for trivial types, as the default
template covers them correctly nowadays.
Finally set up a better default for isPointer, and do some smaller
cleanups all over the place.
Change-Id: I6758ed37dfc701feaaf0ff105cc95e32da9f9c33
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Added functions that tell how much free space is available at the
beginning and at the end of the storage
Updated preconditions of operations to use freeSpace* functions
Also, changed casts uint(this->size) to size_t(this->size)
Task-number: QTBUG-84320
Change-Id: Iad94c1060a00f62068da9d1327e332a00d4f4109
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Refactored certain bits of qarraydataops.h: picked exception-related
building blocks and put them into one place, (somewhat) documented
the usage, added tests
Personally, the existing code seemed rather complicated to analyze
(and do mental experiments for corner cases), especially when staring
at the whole thing for a while or "returning back" from some other work
and I still have my doubts that everything works correctly. Testing the
building blocks that are used should:
a) increase trust into existing code (provided the usage is correct)
b) give more use cases of how to use the building blocks, which in turn
would allow to compare and contrast tests vs implementation
Task-number: QTBUG-84320
Change-Id: I313a1d1817577507fe07a5b9b7d2c90b0969b490
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Updated insert() methods:
* Refined Q_ASSERT() checks
* Fixed implementation issues (some of which resulted in
actual crashes)
* Allowed to insert at the end. This is safe as far as I can
tell and actually would allow to simplify considerable chunks
of code (mainly, copyAppend versions to just return
insert at the end)
Updated tests accordingly
Change-Id: I0ba33ae5034ce8d5ff95b753894e95d71ba00257
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Extended existing tests with QArrayData's allocation options
Added extra tests on array operations covering append, insert,
emplace, erase and truncate. "Raw" QArrayDataPointer is used instead of
test-specific SimpleVector to check the behavior without some custom
logic in-between
The change targets future updates to array operations in the light of
prepend optimization: as the array operations would become more complex,
these tests should give a much better coverage (specifically due to
likely non-trivial implementation details and optimizations)
Task-number: QTBUG-84320
Change-Id: I6581e2cb48f81b82ee5052d1dcea3da2819df47a
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Both normal and relaxed constexpr are required by our new minimum of
C++17.
Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Use pro2cmake with '--api-version 2' to force regenerate
projects to use the new prefixed qt_foo APIs.
Change-Id: I055c4837860319e93aaa6b09d646dda4fc2a4069
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Remove the last places where those got used and avoid
allocations when we resize to 0.
Change-Id: Ib553f4e7ce7cc24c31da15a55a86d18bdf1cc5c3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As a side effect, data() can now return a nullptr. This
has the potential to cause crashes in existig code. To work
around this, return an empty string from QString::data()
and QByteArray::data() for now.
For Qt 6 (and once all our internal issues are fixed), data()
will by default return a nullptr for a null QString, but we'll
offer a #define to enable backwards compatible behavior.
Change-Id: I4f66d97ff1dce3eb99a239f1eab9106fa9b1741a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It has been the case for both QStringLiteral and QByteArrayLiteral
since Qt 5.0, and Q_ARRAY_LITERAL since Qt 6.0.
Since it's definitely surprising, add a note in the docs, which
is "somehow" consistent with the interpretation of capacity as
the biggest possible size before we reallocate. Since it's 0,
any manipulation of the size will cause a reallocation.
(Alternatively: the capacity() is for how many elements memory was
requested from the free store. No memory was allocated, so 0...)
Task-number: QTBUG-84069
Change-Id: I5c7d21a22d1bd8b8d9b71143e33d537ca0224acd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Those members are not required anymore and now part of the
object itself.
Change-Id: If9eb5355ca8f2cf9528f6f63ca4e172acc9f9aed
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This requires that the allocation functions return two pointers: the d
pointer and the pointer to the actual data.
Ported QArrayDataPointer & SimpleVector to the inlined size & data.
For now, the size and offset members are not yet removed from
QArrayData, to let QVector, QByteArray and QString compile unmodified.
Change-Id: I8489300976723d75b8fd5831427b1e2bba486196
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Instead of using the reference count to store whether the data is
sharable and whether the header is immutable, move the settings to the
flags member. This allows us to save one comparison per deref() or
needsDetach(). It also allows for the possibility of mutable data
pointed to by a static header.
Change-Id: Ie678a2ff2bb9bce73497cb6138b431c465b0f3bb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The next change will stop using some values in the reference counter as
settings from the data.
Change-Id: I94df1fe643896373fac2f000fff55bc7708fc807
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The Mutable flag now contains the information on whether the data this
QArrayData points to is mutable. This decouples the mutability /
immutability setting from the allocation and from the type of data,
opening the way for mutable raw or foreign data.
There are still plenty of places in the source code that check the
size of the allocation when it actually wants d->isMutable(). Fixing
this will require reviewing all the code, so is left for later.
The needsDetach() function is moved to QArrayData and
de-constified. It returns true when a reallocation is necessary if the
data is to be modified.
Change-Id: I17e2bc5a3f6ef1f3eba8a205acd9852b95524f57
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
These flags allow us to determine what type of data QArrayData is
carrying. There are currently only two supported types:
- raw data type: constructed via fromRawData or static data
- allocated data type: regular data done via heap allocation
The QArrayData object is usually allocated on the heap, unless its own
reference count is -1 (indicating static const QArrayData). Such
object should have a type of RawDataType, since we can't call free().
Add GrowsBackward for completeness as well as the StaticDataFlags
default for static data.
Change-Id: Icc915a468a2acf2eae91a94e82451f852d382c92
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In almost all cases, use d->allocatedCapacity() or
d->constAllocatedCapacity() instead of d->alloc, since they do the
same thing (right now). In the future, the functions will be
changed. There is a separate const version because most const code
should not need to know the allocation size -- only mutating code
should need to know that
There are a few cases where d->alloc was replaced with a better
alternative, like d->size. The one case that remains in the code will
be replaced by a different test when it's available.
Change-Id: I48135469db4caf150f82df93fff42d2309b23719
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Instead of stealing one bit from the alloc field, let's use a full
32-bit for the flags. The first flag to be in the field is the
CapacityReserved (even though the allocate() function will store some
others there, not relevant for now).
This is done in preparation for the need for more flags necessary
anyway.
Change-Id: I4c997d14743495e0d4558a6fb0a6042eb3d4975d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Rename to QArrayData::ArrayOptions in preparation for these flags
being in the array itself, instead of used just for allocating new
ones.
For that reason, rename QArrayData::Default to
DefaultAllocationFlags. And introduce QArray::DefaultRawFlags to mean
the flags needed for creating a raw (static) QArrayData.
Also rename QArrayData::Grow to GrowsForward, so we may add
GrowsBackward in the future.
Change-Id: I536d9b34124f775d53cf810f62d6b0eaada8daef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The support for unsharable containers has been deprecated
since Qt 5.3.0, so let's finally remove support for them.
Change-Id: I9be31f55208ae4750e8020b10b6e4ad7e8fb3e0e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The macro is not documented, so not part of the public Qt API. It is
made obsolete by the alignof keyword in C++11.
Remove the usage of the macro across qtbase, in particular the
workarounds for compilers that didn't support alignof, and that will
not be supported in Qt 6.
The macro definition is left in place, no need to break existing
code.
Task-number: QTBUG-76414
Change-Id: I1cfedcd4dd748128696cdfb546d97aae4f98c3da
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Some compilers (hello, MSVC) do not produce literal types in Qt
because their constexpr support has been blacklisted.
Therefore, amend the check for literal types in Q_ARRAY_LITERAL:
only do the check if the compiler supports constexpr.
Change-Id: I7cffe00dde447d975aa6a7d02248df9c351508ff
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>