Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74370
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <dcbd572482a25a46d8ae8d01cf755d73.squirrel@webmail.klapt.com>
In-Reply-To: <537A3756.4060900@lerdorf.com>
References:
    <CAF+90c8m8kMNjHOOKWs3iTxnLSVv41pk0mGjgzvvp2+Lieh+ig@mail.gmail.com>
    <53788337.9090006@lerdorf.com>
    <CAEZPtU7XM3Sihz0KyEpfPpYMeLZXvrz-H8SmD4LnP9gDRjNXiA@mail.gmail.com>
    <53789AD9.40109@lerdorf.com>
    <CAEZPtU46qaKtUufaorcRp14_6wr1bHDVkJU5p+S0V+KzNF+jdg@mail.gmail.com>
    <537A35D9.50807@lerdorf.com>
    <CAEZPtU7QUL0Rb-DMFmaa7kw=MFgKUhmOwKw+PwbpDe-4_mt21g@mail.gmail.com>
    <537A3756.4060900@lerdorf.com>
Date: Mon, 19 May 2014 22:55:55 +0200
To: "Rasmus Lerdorf" <rasmus@lerdorf.com>
Cc: "Pierre Joye" <pierre.php@gmail.com>,
 "Nikita Popov" <nikita.ppv@gmail.com>,
 "PHP internals" <internals@lists.php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Rethinking 64bit sizes and PHP-NG
From: anatol.php@belski.net ("Anatol Belski")

On Mon, May 19, 2014 18:54, Rasmus Lerdorf wrote:
> On 5/19/14, 9:52 AM, Pierre Joye wrote:
>
>> On Mon, May 19, 2014 at 6:48 PM, Rasmus Lerdorf <rasmus@lerdorf.com>
>> wrote:
>>
>>
>>> But that is for minor tweaks and optimizations. In this case the way
>>> to optimize the patch is to undo the 64-bitness in a number of places
>>> where it doesn't make sense. Putting in a software-imposed limit on
>>> class size names while still keeping it a 64-bit value in the struct
>>> makes no sense, for example. Same goes for lineno, line_start,
>>> line_end, num_args and a couple more that Nikita pointed out.
>>
>> That's not what we discussed.
>>
>>
>>> And as far as I am concerned this has nothing to do with phpng. I'd
>>> still be voting no on it as a 4% memory increase, which, by the way,
>>> you don't even mention in the impacts section, is still too high for
>>> me when I know parts of the 4% are completely unnecessary.
>>>
>>
>> We answer that already, be from Nikita, Dmitry or I. And yes, we agree
>> on these points already.
>
> Ok, then please update the RFC with what you see as the way forward,
> including adding actual memory impacts to it and restart the vote when the
> RFC is ready.
>
>
> -Rasmus
>
Confused about what is happening. I thought we reached the agreement based
on what Nikita has suggested, which is pretty simple.

The points of the current patch which have to stay

1. 64 bit int in zval(no mem issue, no perf issue)
2. size_t in zend_string (.8% mem issue, no perf issue)
3. use 32 bit string length as much as possible everywhere else

for myself i'd add also
- several ini options (like content, post, etc length, memory_limit and
several other)
- file cursor and stream positions (off_t family)
That doesn't affect mem consumption much as Dmitry already mentioned.

Everything else, say

literal
ini
stack
header
lineno
class names in structs
path length in structs
hash
etc.

has to be adjusted with 32 bit string length while merging with the phpng
branch.

So question - why there are voices like "you have to implement it for
phpng and rewrite the RFC"? If there's the consent to take this RFC with
regard to improvement suggestion listed in short above, so what is wrong
again? Wasn't it said we do it collectively?

Have a nice day.

Anatol