Re: [rfc] 64bit usage, actual memory usage using real life apps

On Thu, May 15, 2014 at 8:50 PM, Marc Bennewitz <php@marc-bennewitz.de> wrote: > Even 4% is very big if you provide a high performance web application. 4% memory increase? Not really. >> There is indeed more memory used but it is less than one could expect >> and very acceptable given the benefits provided by the patch. >> >> Also we may see more gains if class/variable/etc names use int32 >> instead of size_t, as Stas pointed out it makes little sense in this >> case and the implementation is much safer than any other areas in the >> core (or other extensions). >> >> I feel confident that we can even get better results with phpng, once >> we get the time to actually merge the 64bit patch and do further >> analyzes while stabilizing phpng. >> >> I have to ask anyone to actually look at these numbers and the >> benefits (see the other thread "on memory usage with the 64bit patch, >> and interpretation of various numbers"). > > > Pierre, I don't understand you in the following points: > > You argument the size_t for string length is to use well defined C types and > that makes it more safe. But it is only an integer type that can overflow in > the same way any other integer can do. And as Nikita pointed already the > type exists to support ALL possible objects. > In which case it makes it more save? Please see the links in the other thread, it is very well explained, much better that what I could do. > Why you think the size_t type is more safe for string length but in the case > for class names it's ok to use a smaller type? Because we already have safety checks for string lengths etc. We also already had issues related to this area. Take it as a compromise, but still safe (while phpng may bring its lot of issues too, but that's expected). > I often hear in this thread (and phpng) we do support string length up to > 2GB on 32bit systems already and therefore should increase it for 64bit > system to the max possible value. > In my opition it's simply not true in practice because on 32Bit systems your > system can manage max. 2^32bytes and one PHP process isn't the only process. > I think the same argment exits on 64bit system. > So for me we should reduce the max. string length down as nobady can use 2GB > strings in PHP regardless what integer type string length will be ;) I do not care much about the 2G+ limit, as I said already multiple times it is a side effect of this patch, not a goal. > Same for class names which shouldn't be possible to be longer than 255. 255 is not enough, but yes, we do not even need 2G :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org