[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
marc at kdab.com
Wed Sep 11 11:29:32 CEST 2019
On 2019-08-23 10:31, Mutz, Marc via Development wrote:
> If that's the case, shouldn't we run, not walk, to replace our
> internal uses with std::mutex + std::condition_variable to have only
> one mutex?
Since it _is_ the case, I've sat down and ported QReadWriteLock from
QMutex + QWaitCondition to std::mutex and std::condition_variable:
1/8th speed-up in contested write-only cases (readOnly doesn't use the
Private class) may not sound much, but seeing as QRWL is an order of
magnitude slower than std::shared_mutex in this test
(https://codereview.qt-project.org/c/qt/qtbase/+/273595), and with the
pending change to get rid of the QHash in there
(https://codereview.qt-project.org/c/qt/qtbase/+/185849), the speed-up
will become much more pronounced still (my laptop's CPUs are only 50% of
the time in C0 when this test executes, for std::shared_mutex, it's more
like 90%, which gives you an idea of the efficiency gap that needs, and
probably can be, bridged, still).
I think this proves that QWaitCondition not only theoretically (by
counting the mutexes) but also practically can no longer be recommended
for Qt implementation work.
I also question the usefulness of it in new user code, seeing as we'll
probably not go back to backing QMutex by std::mutex just to enjoy the
same optimisation std::condition_variable enjoys over
std::condition_variable_any, which means this class is de-facto
So, will we also deprecate it de-jure?
More information about the Development