yes. We discussed that patch with Pierre for hours, and I always told that
I afraid about memory consumption overhead.
my tests showed it clearly
phpng was started as closed project, because we didn't know if we'll able
to succeed at all (it's not a first attempt) and we liked to move fast.
Once, we got useful results we opened it.
see https://wiki.php.net/phpng#performance_evaluation
Thanks. Dmitry.
On Wed, May 14, 2014 at 12:08 PM, Christian Stoller <stoller@leonex.de>wrote:
> > 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
>