Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Claude Pache]

> Le 12 nov. 2021 à 17:24, Ben Ramsey  a écrit :
> 
> I like this change, but the deprecation in 8.2 seems too disruptive. I’d
> rather promote our intent to deprecate this with a statement in the
> manual that says something like, “This feature will be deprecated in
> PHP 8.3 and removed in 9.0.” Meanwhile, 8.2 should include the
> AllowDynamicProperties attribute so folks can start preparing.
> 

Kindly recalling that the intended meaning of deprecation warnings is duly 
documented in the manual? I have read the manual when I designed my error 
handler many year ago; as a consequence, this deprecation warning will not at 
all be disruptive for me. 

I strongly doubt that a mere statement of intention in the manual is of much 
utility, given that many people apparently don’t read the manual when they 
design their error handlers... We should rather more heavily promote the true 
meaning of “deprecation”.

—Claude

Re: [PHP-DEV] Automatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4

[Deleu]

On Sat, Nov 13, 2021 at 1:31 PM Craig Francis 
wrote:

> On Fri, 12 Nov 2021 at 10:19, Máté Kocsis  wrote:
>
> - Does anyone know how to get some sponsorship from AWS...
>
> Craig
>

You may fill out this form
https://pages.awscloud.com/AWS-Credits-for-Open-Source-Projects to apply
for 12 months credit. If I'm not mistaken it could be a recurring thing by
re-applying every 12 months. It might be important to have a dedicated
account only for the purpose of the benchmark.

You can also read more about it here:
https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/

-- 
Marco Aurélio Deleu

Re: [PHP-DEV] Automatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4

[Marco Pivetta]

Hey Máté,

On Fri, Nov 12, 2021 at 11:19 AM Máté Kocsis  wrote:

> Hello Internals,
>
> I'm writing this email because lately, I've been working on an automatic
> benchmarking framework for PHP, and I'd like to share some news regarding
> it. The initial implementation
> was sponsored by Craig Francis, and it was used for the evaluation of the
> performance aspects of the is_literal() RFC. Since then, I fixed numerous
> issues and implemented many new features, so with the very close advent of
> PHP 8.1, the time has come to unveil it.
>
> I'm sure that many of you still remember Intel's automatic benchmarks from
> a couple of years ago (e.g. https://externals.io/message/89843#89843). I
> loved these emails, so this project served as a great inspiration for me
> to start working on something similar. I have to admit
> though that I won't be able to replicate their extremely advanced setup.
>
> My main goal was to develop a framework (
> https://github.com/kocsismate/php-version-benchmarks) which is:
> - fully automatic so that it can be easily run regularly, and the
> benchmarks are reproducible
> - it's possible to try it out locally via Docker, but it can be run in the
> cloud (currently, only AWS is
> supported), and the instance type is configurable
> - supports different CPU platforms (X86-64 and ARM64), and advanced options
> whether
> turbo boost/hyper threading/deeper CPU C-states are enabled is configurable
> - supports any version of PHP since PHP 7.4, including any git branches or
> commits
> - supports the most important PHP configurations, including whether
> OPcache/JIT/preloading
> is enabled
> - supports multiple tests: currently, the micro benchmarks bundled with
> php-src, as well as the
> Symfony and the Laravel demo sites as "real-life" tests are included with
> some customizability (number of warmups, iterations number, number of
> requests)
> - results are measured via using PHP-CGI which is a lightweight web server
> with very a small overhead
>
> The most current benchmark is available at
>
> https://github.com/kocsismate/php-version-benchmarks/blob/main/docs/results/2021_11_11_09_20_1_aws_arm64_c6g_4xlarge/result.md
> . I'm happy to share that the results suggest PHP 8.1.0 is around 28-32%
> faster than PHP 7.4 in real-life tests, and a few percent faster when it
> comes to micro benchmarks. The benchmark was performed on an ARM64 instance
> because this platform provided much more stable results than X86-64-based
> ones did, mainly due to their fixed CPU frequency.
>
> Unfortunately, the benchmark is not yet suitable for detecting minor
> performance changes between commits as the run-to-run variation of the
> results is a bit too high; in some cases, it can be up to 1-2%. I hope that
> this problem can be mitigated to an acceptable level in the future, but
> most probably I'll need some help to achieve this. So any help is
> appreciated!
>
> Furthermore, I'd have some questions regarding this project:
> - Would you welcome automatic emails on internals (or on a dedicated
> mailing list), just like how
> Intel did it? I'm not sure about the frequency, but in my opinion,
> 1-2/month would be a sensible one, given there is interest in it.
> - Does anyone know how to get some sponsorship from AWS (or from some other
> cloud
> provider at last resort)? I already tried to apply for AWS Activate's free
> credits, but my application was rejected due to different reasons
> (normally, this program is available for startups). I have some hope that
> running the benchmark on a dedicated instance would decrease variation of
> the results, but enabling this feature is relatively expensive compared to
> other costs, so I'd be very happy if I wouldn't have to sponsor all of
> this, when I already dedicate a great deal of my time to the cause.
> - As always, I'm happy to receive feedback and improvements (ideally along
> with an implementation :) ). For example, currently I've started working on
> some visualization and chart support, but frontend stuff is not my area of
> expertise, so I'm progressing a bit slower than normally. Also, the
> statistical foundations could be reviewed, and possibly improved.
>
> Regards:
> Máté
>

Nice results, and nice project!

Overall against having it on the ML: I set up a filter to ignore those
pesky emails by Intel.
As much as I appreciate their effort, they were really noisy, and not
really useful to the larger group.

If your tool could export the results in machine format with something like
an attached XSD or JSON-Schema, it would be possible to build UIs like
https://arewefastyet.com/ , without the need to resort to a notification
model.
What's needed is to save them in a branch on the repo (or similar approach)
for later consumption.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Fri, Nov 12, 2021 at 11:19 AM Máté Kocsis  wrote:

> Hello Internals,
>
> I'm writing this email because lately, I've been working on an 

Re: [PHP-DEV] Automatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4

[Craig Francis]

On Fri, 12 Nov 2021 at 10:19, Máté Kocsis  wrote:

> Furthermore, I'd have some questions regarding this project:
> - Would you welcome automatic emails on internals (or on a dedicated
> mailing list), just like how Intel did it? I'm not sure about the
> frequency, but in my opinion, 1-2/month would be a sensible one, given
> there is interest in it.



I'm sure you know this already, but I'd be interested... I quite like
knowing when regressions have happened as soon as possible; and having
something which is keeping an eye on things, would hopefully highlight
issues sooner.


- Does anyone know how to get some sponsorship from AWS...



Very funny, Amazon paying :-P


- As always, I'm happy to receive feedback and improvements (ideally along
> with an implementation :) ). For example, currently I've started working on
> some visualization and chart support, but frontend stuff is not my area of
> expertise...



For my sins, I can do some frontend stuff... are we talking CSS, SVG, and
maybe a bit of the old JavaScript? If so, feel free to contact me off-list,
I probably can't do anything in the next week or two, but I'm
optimistically (naively) hoping I can clear some of my todo list :-)

Craig

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Victor Bolshov]

The way I see it, it might look similar to strict_types opt-in, but 
only on the surface. The amount of changes needed to make legacy code 
compliant with strict_types directive, would be tremendous, also there 
would be no simple one-size-fits-all solution like the 
#[AllowDynamicProperties]. In that sense, these two are hardly 
comparable.


I agree with the change (not that I have a voting karma, just 
watching). I also agree with Andreas Heigl saying that at certain point 
changes like this probably should happen, and regardless of exactly 
when, it is going to cause debate and complaints, but we as community 
should probably prefer having a long deprecation cycle for smoother 
transition, which is why the suggested timeline is IMO good (that is, 
if the community represented by core devs will vote for this RFC).


Opt-in strategy - #[DenyDynamicProperties] - for a change like this 
would effectively do nothing. I personally would be against this change 
at all then.


Many thanks to the PHP team from userland, also for letting anyone 
voice their thoughts and concerns on important matters!


Regards,
Victor Bolshov,
Software developer

On za, nov 13, 2021 at 08:26, Peter Bowyer  
wrote:
On Sat, 13 Nov 2021, 00:14 Christoph M. Becker, > wrote:



 Offering an
 opt-out of dynamic properties or some switch to disable the 
deprecation

 would not help in that regard.



Given this is a big change to the way PHP has behaved for decades I 
did
wonder why the RFC didn't propose an opt-out of dynamic properties 
rather
than opt-in, preserving the long-term language behaviour. So thanks 
for

covering that.

I think you and the PHP internals community will be surprised by how 
widely
used dynamic properties are. I read through a handful of WordPress 
plugins
we have installed and found a few. And in my own where I'm using a 
named

class instead of an array.

I work with modern framework based code most of the time and I find 
it easy

to forget what is out there as quintessential or traditional PHP code.

Whether we have #[AllowDynamicProperties] or #[DenyDynamicProperties] 
one

set of PHP users is going to be doing a find & replace across their
codebase.

From a DX perspective I'd rather have #[DenyDynamicProperties] as 
it's like

declaring strict_mode and opt-in.

Either way are the planned engine changes feasible, as the feature of
dynamic properties stays in the language but toggled off/on per class?

Peter

Re: [PHP-DEV] Automatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4

[Côme Chilliet]

Le 12 novembre 2021 11:18:50 GMT+01:00, "Máté Kocsis"  
a écrit :
>
>Furthermore, I'd have some questions regarding this project:
>- Would you welcome automatic emails on internals (or on a dedicated
>mailing list), just like how
>Intel did it? I'm not sure about the frequency, but in my opinion,
>1-2/month would be a sensible one, given there is interest in it.

I would favor having this on a website, with an atom/rss feed. But I'm not 
against having it on the ML, but more like when there is an RC or when some 
change have significant impact.

>- As always, I'm happy to receive feedback and improvements (ideally
>along
>with an implementation :) ). For example, currently I've started
>working on
>some visualization and chart support, but frontend stuff is not my area
>of
>expertise, so I'm progressing a bit slower than normally. Also, the
>statistical foundations could be reviewed, and possibly improved.

The link to the results in the readme points to 
https://kocsismate.github.io/php-version-benchmarks/index.html which is empty. 
Maybe this is known.
Charts 

This quite nice!
Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Peter Bowyer]

On Sat, 13 Nov 2021, 00:14 Christoph M. Becker,  wrote:

> Offering an
> opt-out of dynamic properties or some switch to disable the deprecation
> would not help in that regard.
>

Given this is a big change to the way PHP has behaved for decades I did
wonder why the RFC didn't propose an opt-out of dynamic properties rather
than opt-in, preserving the long-term language behaviour. So thanks for
covering that.

I think you and the PHP internals community will be surprised by how widely
used dynamic properties are. I read through a handful of WordPress plugins
we have installed and found a few. And in my own where I'm using a named
class instead of an array.

I work with modern framework based code most of the time and I find it easy
to forget what is out there as quintessential or traditional PHP code.

Whether we have #[AllowDynamicProperties] or #[DenyDynamicProperties] one
set of PHP users is going to be doing a find & replace across their
codebase.

>From a DX perspective I'd rather have #[DenyDynamicProperties] as it's like
declaring strict_mode and opt-in.

Either way are the planned engine changes feasible, as the feature of
dynamic properties stays in the language but toggled off/on per class?

Peter

>