> Well put Nikita!
>
> Guys - we're in a bit of a ridiculous situation where the key low-level
> engine maintainers are saying this patch is unacceptable, yet it may pass
> due to the low level of overall interest and the lack of special rules to
> govern low-level changes like that (where with all due respect, I think the
> main maintainers of the engine should get much stronger power).
>
> The patch the way it is now should be discarded; All the macro changes, as
> well as any data structure change except for IS_LONG should be removed.
>
> Given that the current RFC doesn't thoroughly represent the performance hit
> (in terms of memory footprint, as well as resulting performance hit -
> especially when using phpng), I recommend the following:
>
> * Add the relevant performance feedback from Dmitry to the RFC, as well as
> his concerns as the chief performance guy php.net has
> * Provide an option for people to vote 'yes' for the IS_LONG size part only
>
> If the authors of the RFC object, my request from everyone who has voting
> rights here is to vote 'no' and we can create a separate RFC for the IS_LONG
> part only. Forcing this change against the explicit concerns of Dmitry and
> Nikita, who worked their rear ends off to squeeze every bit of performance
> in phpng (along with Xinchen, and now others joining in) - is, well,
> ridiculous IMHO.
>
> Zeev
>
>> Sorry, what did I miss here? Why cannot the phpng numbers be taken as
>> "valid"?
>> The very same issue also exists in our current implementation. In phpng
>> the
>> relative hit is just larger, because the structures are more optimized.
>>
>> I think you shouldn't dismiss Dmitry's point just like that. Having
>> support for 64
>> bit integers on Windows and other LLP64 architectures - that's great.
>> Making
>> string lengths unsigned - that's great as well. But supporting strings
>> larger than
>> 4G or arrays with more than 4 billion elements - that does not seem very
>> useful
>> and unlike the other two changes, hurts memory usage. I wonder how many
>> people would prefer having lower memory usage over having the ability to
>> create arrays with 4 billion elements.
>>
>> Independently of that: In a lot of the previous discussion people have
>> many,
>> many, many times asked that this patch be implemented without all those
>> macros renames and zpp changes. I still have a hard time seeing the
>> benefit of
>> doing that. The zpp changes also conflict with phpng, because S has a
>> different
>> meaning (and imho for no good reason - it could just as well stay at s).
>>
>> Nikita
>
I am not a developer, but I think the approach of the phpng developers is not fair. The 64 bit topic
and its RFC has been worked on and discussed for weeks or months and now theirs suddenly phpng and
all the former work should be thrown away?
I have not followed the whole discussion about 64 bit/size_t, etc, so I just want to ask if you,
Nikita, Dmitry or Zeev have mentioned your view and the issues before?
Christian