Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74234
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain marc-bennewitz.de does not designate 80.237.132.171 as permitted sender)
Message-ID: <53750C90.5070200@marc-bennewitz.de>
Date: Thu, 15 May 2014 20:50:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEZPtU6xpcGHTTrohn3QTR==2e1Umv4KGsb91JXU0qN-sP2Yjg@mail.gmail.com>
In-Reply-To: <CAEZPtU6xpcGHTTrohn3QTR==2e1Umv4KGsb91JXU0qN-sP2Yjg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [rfc] 64bit usage, actual memory usage using real life
 apps
From: php@marc-bennewitz.de (Marc Bennewitz)


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,
>