On October 20, 2015 08:43:26 Thiago Macieira <thiago.macie...@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. > 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. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Sent from cellphone _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
