Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74237
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53750C90.5070200@marc-bennewitz.de>
References: <CAEZPtU6xpcGHTTrohn3QTR==2e1Umv4KGsb91JXU0qN-sP2Yjg@mail.gmail.com>
	<53750C90.5070200@marc-bennewitz.de>
Date: Thu, 15 May 2014 22:35:16 +0200
Message-ID: <CAEZPtU4egbs1SCwgcJ-X4e_s53VgiOSfy4t9sBAxgsX=EYAUGg@mail.gmail.com>
To: Marc Bennewitz <php@marc-bennewitz.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [rfc] 64bit usage, actual memory usage using real life apps
From: pierre.php@gmail.com (Pierre Joye)

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