On 20/10/15 09:59, "Bubke Marco" <marco.bu...@theqtcompany.com> wrote:
>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. 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development