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

[Bubke Marco]

On October 20, 2015 10:10:36 Knoll Lars <Lars.Knoll at theqtcompany.com> wrote:

> 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.

We should be careful not to get the new motif too. ;-) I think we have to find a middle ground again and again. It's  a question of how much pain our actions are producing and how much our inactions.  ;-) 

>> 
>>
>>> 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
Sent from cellphone