Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74216
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLtcL_ouZgy8DcggX4+VUk3fg3j5+BWQcRG9tAy-Xi_WVQ@mail.gmail.com>
References: <CAEZPtU6xpcGHTTrohn3QTR==2e1Umv4KGsb91JXU0qN-sP2Yjg@mail.gmail.com>
	<CA+9eiLtcL_ouZgy8DcggX4+VUk3fg3j5+BWQcRG9tAy-Xi_WVQ@mail.gmail.com>
Date: Thu, 15 May 2014 08:20:56 +0200
Message-ID: <CAEZPtU5VF2CMDysjucKu+XnMSiHd0JEr0daiJBDwyRrK-gSquA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
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:09 AM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>
> On Thu, May 15, 2014 at 3:33 AM, Pierre Joye <pierre.php@gmail.com> 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%
>>
>> 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).
>
>
> Read "more gain" as "less degradation".

No, I mean more gain.

But it is nice to see that actual numbers are being ignored, we go
from your 8% to a medium increase to something closed to the "measures
margin errors" level, but heh, who cares?

>> 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 wouldn't be so confident, before seeing the results.

Which won't and can't be seen before phpng is somehow usable and
testable. We are very far away from that.

> The relative memory consumption increase on phpng is going to be more
> significant.

With the risk to repeat myself, phpng is by far not ready. We have
proven that the impact of the 64bit patch is not significant, from a
memory and performance point of view. The memory results can be seen
here and in the other tests we published. The performance as well, and
we have to keep in mind that it performs equally or better with many
widely used applications.

Now, for what I understand, no matter what we do or provide, you guys
are going to refuse this patch, with absolutely no valid reason but an
hypothetical change that may be ready in a timely manner for php-next.
Given that it is in an acceptable state, both from a stability and API
point of view. This is definitively a bad thing and I am not sure that
will end well for php as a project or language. Or did I miss
something that could tell me that you may actually be more
cooperative?

Cheers,
Pierre