Morning internals,
I have improved the performance of the patch a little, here's the
results of a bad run:
krakjoe@fiji:/usr/src/php-src$ sapi/cli/php -n prop.php
empty_loop 0.064
write_prop1() 0.088 0.025
write_prop2() 0.079 0.016
write_prop3() 0.082 0.018
------------------------
Total 0.314
There is going to be overhead, not the kind we can't minimize, or
justify though.
Dmitry has said he'll review, and I'm hoping at least Laruence, Nikita,
and Bob will do the same ...
We have many weeks to improve the implementation, I'm not going to
merge anything that's obviously bad :)
Cheers
Joe
On Mon, May 23, 2016 at 10:54 AM, Julien Pauli <jpa...@php.net> wrote:
> On Mon, May 23, 2016 at 11:09 AM, Stanislav Malyshev
> <smalys...@gmail.com> wrote:
> > Hi!
> >
> >> The performance effect of this implementation is terrible.
> >>
> >> Assignment to typed property is 2.3 times slower.
> >> Assignment to untyped property in a class with typed properties is 1.8
> times slower.
> >>
> >> See the benchmark
> >> https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800
> >
> > This is not good. I wonder why these tests weren't made before the vote
> > and results wheren't added in the RFC. Should we make it a standard
> > practice to do so? Having 2x slowdown on each property access sounds
> > like a bad idea.
>
> The question is :
> * should the vote be an idea-based vote, or integrate the code into the
> vote ?
>
> My vote did not integrate the code, but the feature.
>
> The idea is that if the RFC passes, then the feature is agreed, and we
> still have some time to find a better implementation.
> If we could not find one, then the feature should be abandoned or
> post-poned until a new patch. If the new patch changes the
> implementation, then the RFC should be reopened.
>
> My thoughts.
>
> Julien.Pauli
>
