[Development] Feature Freeze Exception: QStringView
philwave at gmail.com
Tue Jan 31 13:50:26 CET 2017
As far as I understand, I see a performance regression with QStringView, for all the cases where copy-on-write can't take place any longer.
In the following code, an extra malloc is needed. Or am I wrong?
void foo(QStringView sv)
QString str(sv); // malloc needed
void foo2(const QString& s)
QString str(s); // faster because of COW
On Mon, 30 Jan 2017 20:03:24 +0100
Marc Mutz <marc.mutz at kdab.com> wrote:
> QStringView is ready to be merged, but the maintainer has asked for another
> week before he can properly review the class.
> In case you don't remember, here's the discussion thread from 2015:
> Here's the evolving patch series:
> I feel the patch addresses all concerns raised in the discussion:
> 1. size_type: we agreed on on ssize_t equivalent to strike a balance between
> the Qt preference of 32-bit signed types over the STL preference for 64-bit
> unsigned types.
> 2. Do this in Qt vs. do this in QtCreator. I believe that a QStringView
> without deeply-routed support in QString would be a still-born. We also
> don't have time come Qt 6 to port all of Qt to a QStringView developed
> elsewhere. The current patches just scratch the surface. Everywhere
> QStringRef is currently used, QStringView can be used. And a lot of places
> that traditionally only took QString should take QStringView, too, e.g.
> QFile::encodeName(). So I added it to Qt.
> 3. Keeping existing QString overloads for implicit sharing.
> The patch does not remove anything. It will, as it progresses, implement
> QT_STRINGVIEW_LEVELs 2 and 3 which remove existing QString and QStringRef
> overloads (2: only where the function read from the string, 3: also where
> it stores the string), so that at some later point in time we can just flip
> a preprocessor switch and compare executable size and execution speed of
> both sets of overloads, everything else being equal.
> So, in order to give the maintainers more time for review, I'd like to ask for
> a feature freeze extension for QStringView until end of next week, plus a few
> days to deal with maintainer review comments.
> Why should it be granted? Because QStringView is by far the biggest revolution
> in Qt since 5.0, all the while integrating naturally and step-by-step into
> existing code, _tremendously_ simplifying it along the way (cf. the commits
> that start to make use of QStringView: https://codereview.qt-
> project.org/183864 https://codereview.qt-project.org/183925), esp. where, in
> private API, we can already remove the other overloads.
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> Development mailing list
> Development at qt-project.org
More information about the Development