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

From: Date: Thu, 15 May 2014 18:50:56 +0000
Subject: Re: [rfc] 64bit usage, actual memory usage using real life apps
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-74234@lists.php.net to get a copy of this message
On 15.05.2014 01:33, Pierre Joye wrote:
hi, So here are the first numbers: peak mem usage: Wordpress master: 24.33Mb Wordpress str_size_and_int64: 25.72Mb delta 5.4% Symfony master: 26.59Mb Symfony str_size_and_int64: 27.19Mb delta 2.2% Drupal master: 23.46MB Drupal str_size_and_int64: 24.60Mb delta 4.63%
Even 4% is very big if you provide a high performance web application.
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? 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? If it is so very important on some very very special applications a compiler switch would be most logical way to go. 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 ;) Same for class names which shouldn't be possible to be longer than 255.
Cheers,


« previous php.internals (#74234) next »