Re: Revisiting RFC: Engine Warnings -- Undefined array index
| From: | Robert Landers | Date: | Tue, 13 Dec 2022 12:26:14 +0000 |
| Subject: | Re: Revisiting RFC: Engine Warnings -- Undefined array index | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119116@lists.php.net to get a copy of this message | ||
On Tue, Dec 13, 2022 at 11:16 AM Andreas Leathley <a.leathley@gmx.net> wrote:
>
> On 13.12.22 11:01, Robert Landers wrote:
> > intended: ($a['foo'] ?? null) || ($a['bar'] ?? null)
> > Further, writing code like this increases the number of opcodes needed
> > to perform relatively simple logic by ~150%, increasing end-user
> > latency and spending CPU cycles somewhat needlessly.
> I think it is quite the opposite: calling the error handler because of
> E_NOTICE (or now E_WARNING) is quite the additional overhead, and if
> projects just ignore E_NOTICE their applications will be slowed down
> because of that, while fixing the code will avoid the error handler
> altogether. Just because something is longer to write in a programming
> language also does not make it necessarily slower. But if you have any
> actual measurements why using the null coalescing operator would slow
> down code in general that would be something useful to share.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Ah, that's a good point. I ran some tests and was surprised that it
was slower due to needing to call the error handler. I even disabled
E_WARNING in my php.ini to see if that made a difference (it did, but
still not the same quite as fast as using null coalesce).
Results are here:
https://gist.github.com/withinboredom/bd7276b7703663c26c12a18820747bcb
Interestingly the null coalesces used more memory. That surprised me
and was unexpected. Apparently using coalesce requires some temporary
variables to work. Perhaps there would be a benefit for a
FETCH_DIM_IS_COALESCE opcode?