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

[Knoll Lars]

On 20/10/15 09:59, "Bubke Marco" <Marco.Bubke at theqtcompany.com> wrote:

>On October 20, 2015 08:43:26 Thiago Macieira <thiago.macieira at intel.com>
>wrote:
>
>> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote:
>>> So if deep copies loose their ineffciency myth, what reason remains to
>>>not
>>> use  QSV in all functions taking QString?
>>
>> Complicating the API.
>>
>> You cannot possibly prove that doing something O(n) is as efficient as
>>doing 
>> something O(1), therefore there's no way that deep copies would be a
>>myth.
>
>We both know that depends on the size. The minimal size of what the CPU
>gets from the memory is a cache line. The size of a cache line today is
>typically 64 bytes. So as a minimum you always push that much data
>around. So if you use a atomic pointer on more than one cpu this cache
>lines has to be copied all the time. If you change something everything
>which depends on it has to be wait or recompute. So if  you accidentally
>have data on the some cache line it is  shared too. This is not very
>intuitive. Your application can be much slower because you accidentally
>share data. 
>
>Okay that is simplified but we get the picture. And the worst part is
>that memory is so much slower in relation to cache access as it was for
>the difference between memory and hard disks in the paste.  Today the
>difference between caches and memories resemble more that I learned about
>databases 20 years ago. And there you learned to be careful about the
>complexity notations which doesn't reason about different memory speeds.
>
>COW with strings can lead to more coping than simply coping the string
>because most strings are small. Sharing writeable cache lines between
>different cpu is asking for trouble but I  think you know Amdahl's law
>https://en.wikipedia.org/wiki/Amdahl%27s_law.
>
>So why we don't measure it? Lets compile some applications with different
>implementation. Not simple ones. Maybe qtcreator would be a good idea.

Experimenting with that is probably a good idea, but we certainly can’t
change away from COW any time soon. Maybe not ever because of
compatibility concerns.
> 
>
>> COW may have comparable performance to deep copies if you consider the
>>whole 
>> picture and code written properly. Our code was written for COW, so I
>>doubt 
>> that you would get the same performance by suddenly making deep copies.
>>
>> To summarise:
>>
>> 1) I'm ok with adding QStringView
>> 2) I'm ok with using QStringView in applications, no restraints
>> 3) I'm ok with exploring the use in API, in parameters
>> 4) I'm ok with exploring it in return values, in very limited
>>conditions that 
>> are being studied very well, ahead of time
>>
>> Exploring does not mean you can go and start adding overloads
>>everywhere.
>
>I think that's a very good approach.

+1.

Cheers,
Lars