Re: Rethinking 64bit sizes and PHP-NG

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