[Development] Feature Freeze Exception: QStringView

[Philippe]

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 bar()
{
	QString s("hello");
	foo(s)
}

void foo(QStringView sv)
{
	QString str(sv);	// malloc needed
}

void foo2(const QString& s)
{
	QString str(s);	// faster because of COW
}

Philippe


On Mon, 30 Jan 2017 20:03:24 +0100
Marc Mutz <marc.mutz at kdab.com> wrote:

> Hi,
> 
> 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: 
> http://lists.qt-project.org/pipermail/development/2015-October/023358.html
> 
> Here's the evolving patch series:
> https://codereview.qt-
> project.org/#/q/status:open+project:qt/qtbase+topic:qstringview,n,z
> 
> 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.
> 
> Thanks,
> Marc
> 
> -- 
> 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
> http://lists.qt-project.org/mailman/listinfo/development