[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

Sat Oct 17 15:51:35 CEST 2015

>Please understand my POV: I am of the firm belief that Qt has no business
>creating inefficiencies for its users by sloppy implementation. Anywhere.

I think you are overreacting here, way too much. You have discovered a more efficient way to handle strings, but that doesn't mean Trolltech created inefficiency by a sloppy implementation of QString. QString has been used productively by many users for a long time. The fact that a moere efficient implementation exists doesn't mean the current implementation is inefficient. 

>And please don't forget that QString fanboys can continue to massacre the heap
>if they so wish. After all, we've had QStringRef for a long time now, but most
>people still write str.mid(n).toInt() instead of str.midRef().toInt().

But that is because we don't explain in the documentation the most efficient ways to use these classes together. And the reason it isn't in the documentation is we who write the documentation don't know what you know.

>I find it intolerable that todays software
>takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs
>done in less wallclock time than software 20 years ago.

But the fact is, it usually IS tolerable, because the applications you are talking about mostly work in human time.

Your efforts to improve Qt are most appreciated, but you make it sound like we should publicly name and shame all the engineers who ever worked on QString but who failed to find the holy grail of the most efficient implementation.

I had no idea my heap was in such pain.

martin

________________________________________
From: development-bounces+martin.smith=theqtcompany.com at qt-project.org <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on behalf of Marc Mutz <marc.mutz at kdab.com>
Sent: Saturday, October 17, 2015 1:18 AM
To: development at qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt        APIs taking strings

Kurt,

The mail you're replying to has nothing to do with QStringView. It was a
tangent about std::string_view.

If you need a real-world example of where QStringView would be handy: Some
3rd-party code returns you a char16_t *path, and you want to perform a
QDir::cd(). Currently, you need to create a QString (which allocates). Had
QDir::cd() taken a QStringView, you wouldn't have that allocation.

Another example I already mentioned:

> E.g. local QStrings could be replaced by QVarLengthArray<QChar>,
>
> e.g. in code like this:
>     QString joinstr = QLatin1String("\"\n");
>     joinstr += indent;
>     joinstr += indent;
>     joinstr += QLatin1Char('"');
>
>     QString rc(QLatin1Char('"'));
>     rc += result.join(joinstr);
>     rc += QLatin1Char('"');
>
> Even when replaced with QStringBuilder:
>     QString joinstr = QLatin1String("\"\n") + indent + indent
>
>                        + QLatin1Char('"');
>
>     QString rc = QLatin1Char('"') + result.join(joinstr) +
>     QLatin1Char('"');
>
> But the main benefit would be that we only ever need one overload for a
> QString-taking function, not N, N > 3.

Final with QStringView (and a minor modification to QStringBuilder):

  QVarLengthArray<QChar> joinstr // doesn't alloc (for most 'indent's)
      = QLatin1String("\"\n") + indent + indent + QLatin1Char('"');

  // in this line, QStringList::join() doesn't know about QVarLengthArray.
  // but it takes a QStringView and therefore transparently accepts QVLA
  QString rc = QLatin1Char('"') + result.join(joinstr) + QLatin1Char('"');

Please understand my POV: I am of the firm belief that Qt has no business
creating inefficiencies for its users by sloppy implementation. Anywhere. We
cannot know whether one user is calling QString::multiArg() in a tight loop.
It might be dominating her runtime. 99.9% of users probably couldn't care less
about QString::multiArg() performance. But we need to care about the 0.1%,
because that number is much closer to 100% if you integrate it over all users'
critical paths (iow: every Qt user will have *some* part of Qt that she wished
was faster, heck, iirc KMail ran into QObject::connect as a bottleneck at some
point in the past!).

The inefficiencies I (and Sergio and Milian and, I'm happy to see, Friedemann,
and others) care about are not ones you will find in a profiler in those 99.9%
of cases, because they are not used in a critical path. But even for the 99.9%
of users, if we make all of Qt 10% faster on average, their apps will run
close to 10% faster, too. Automatically.

So yes, I care about performance. I find it intolerable that todays software
takes 1000x the memory, 1000x the CPU capacity and doesn't get a given jobs
done in less wallclock time than software 20 years ago. And people don't use
C++ because it's pretty. You cannot compete with Java on programmer efficiency.
Its standard library is orders of magnitude larger than C++'s. People choose
C++ (and accept the associated loss in programmer efficiency), because they
require the bare metal efficiency of C++. And if Qt gets in the way, they will
look for alternatives and find them in places that make Qt look like paradise.

That said, QStringView is as much about

- slim interface type vs. thick, fat, storage type
- interop with 3rd-party and native code

than it is about efficiency.

Bottomline: I don't need a fancy anylysis to tell me that less allocations =
faster programs = more happy Qt users.

And please don't forget that QString fanboys can continue to massacre the heap
if they so wish. After all, we've had QStringRef for a long time now, but most
people still write str.mid(n).toInt() instead of str.midRef().toInt().
QStringView won't change that: A function taking QStringView accepts a
QString, too (either by implicit conversion, or where it makes sence, by
QString overload).

Thanks,
Marc

On Friday 16 October 2015 21:42:23 Kurt Pattyn wrote:
> Marc,
>
> It is clear that your main concern is performance (needless conversions)
> and convenience (being able to work efficiently with 3rd party libraries).
> Regarding performance, I think it would be good if we could come up with
> some numbers. How 'bad' is the current implementation compared to an
> 'ideal' situation? And then define some acceptable target keeping into
> account convenience. Otherwise I am afraid that discussions can keep going
> forever over 1 instruction more or less. Regarding convenience, and that
> is what Qt is all about, I think you made a tremendous proposal that can
> really bring Qt a big step forward. The idea is very sound and clear. Of
> course, there are technical challenges, but that is what we are supposed
> to solve.
>
> I also agree that we should aim for simplicity. QString and QStringView is
> simple to understand, iff we can get rid of all other string related
> classes. The ideal case would be just to have one QString class, although
> I doubt that is achievable.
>
> I think it would be good to come up with some real-world use-cases that
> show how a Qt user and a Qt application could benefit from your proposal.
> Personally, I never experienced a performance problem with QString; but
> then the applications I write are not very string oriented. I am a QString
> aficionado :-)
>
> After all, what I really like about Qt is convenience, simplicity and
> portability. I think this should be the main focus of Qt, and that also
> implies smooth collaboration with the outside world.
>
> Cheers,
>
> Kurt
>
> > On 16 Oct 2015, at 21:47, Marc Mutz <marc.mutz at kdab.com> wrote:
> >> On Friday 16 October 2015 19:31:50 Thiago Macieira wrote:
> >> The conversion from one to the other is one instruction.
> >
> > Which is one instruction too much for tail-call optimisation, e.g.
> >
> > But the point was about std::string_view binary compatibility. As
> > basically a C struct with no ownership semantics, it would be a perfect
> > vehicle to pass strings around different programming languages and
> > compilers, but only if the ABI (ie. the data members) were specified.

--
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 Experts
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development