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
« previous php.internals (#74365) next »