Re: Rethinking 64bit sizes and PHP-NG

From: Date: Mon, 19 May 2014 16:48:25 +0000
Subject: Re: Rethinking 64bit sizes and PHP-NG
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-74365@lists.php.net to get a copy of this message
On 5/18/14, 9:39 AM, Pierre Joye wrote:
> On Sun, May 18, 2014 at 1:34 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> 
>> You keep talking about side effects of the patch.
> 
> No, what I have to keep saying, because this argument keeps coming, is
> that the ability to store >2GB string is a side effect and not a goal
> of this patch.
> 
>> It is these side
>> effects that we have a problem with. We need a version of the patch that
>> doesn't have all these undesired side effects.
> 
> The only one, and it is disputable, is the memory usage, which is
> around 4% under real world usage (WP, Symfony, Drupal, and some other
> apps). It even performs better in many common situations.
> 
>> You put the patch as it stands up for a vote and it is this patch we
>> have to vote on which is why I am voting no on it. It isn't some future
>> version with some unknown number of side effects removed.
> 
> I am not sure how to formulate it in a better way but let me try again.
> 
> - 64bit patch has been worked on and stabilized since months
> - It is continuously tested using master, 5.5 and 5.6, using our full
> tests suite (which is much more than just running phpt in cli if you
> remember)
> - the patch is stable
> 
> Given these points, and as it is the case with every new
> features/addition/improvements we have made, tweaks, optimization,
> etc. will happen after it gets approved and applied. Stability and
> correctness have the priority.

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.

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.

-Rasmus



Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc

Thread (34 messages)

« previous php.internals (#74365) next »