Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74218
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.220.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU5VF2CMDysjucKu+XnMSiHd0JEr0daiJBDwyRrK-gSquA@mail.gmail.com>
References: <CAEZPtU6xpcGHTTrohn3QTR==2e1Umv4KGsb91JXU0qN-sP2Yjg@mail.gmail.com>
	<CA+9eiLtcL_ouZgy8DcggX4+VUk3fg3j5+BWQcRG9tAy-Xi_WVQ@mail.gmail.com>
	<CAEZPtU5VF2CMDysjucKu+XnMSiHd0JEr0daiJBDwyRrK-gSquA@mail.gmail.com>
Date: Thu, 15 May 2014 12:56:04 +0400
Message-ID: <CA+9eiLs+XzJSWDr25mncB0Tngr9pJ4z3KLhp1k7_pXk4c_517g@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec51b9a8d96a7b804f96c77b4
Subject: Re: [PHP-DEV] [rfc] 64bit usage, actual memory usage using real life apps
From: dmitry@zend.com (Dmitry Stogov)

--bcaec51b9a8d96a7b804f96c77b4
Content-Type: text/plain; charset=UTF-8

On Thu, May 15, 2014 at 10:20 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> 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 used memory_get_peak_usage() for measurement. It doesn't provide any
measurement error.
It looks like you measured something else as the absolute numbers are
really different.


>
> >> 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.
>

you may measure the speed and memory consumption difference between master
and pnphg.
we can't do it for your patch on top of phpng yet, because it's not ready.


>
> > 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.
>

+1MB per process is not insignificant taking in account the amount of CPU
cache.


>
> 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?
>

I tried to be cooperative, and discussed this patch with you proposing
taking it into phpng part by part and proving that each part doesn't make
significant harm. You liked agreement for all at once even if it's not
implemented for phpng. Once I saw the memory overhead, I made my decision -
that it's not acceptable.

Anyway, I'll try to be more cooperative :)
but it doesn't mean that I'll take decisions that I don't like.

Thanks. Dmitry.


>
> Cheers,
> Pierre
>

--bcaec51b9a8d96a7b804f96c77b4--