Re: Rethinking 64bit sizes and PHP-NG

On 5/19/14, 1:55 PM, Anatol Belski wrote: > 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? I am fine saying we have a consensus on doing it this way, but it is quite different from what the current RFC says. At least make a note of this in the RFC then since many people use accepted RFCs as a resource later on to figure out what has changed. -Rasmus

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