On Apr 2, 2026, at 11:25 AM, Matthew Weier O'Phinney <[email protected]>
wrote:
>
> On Wed, Mar 11, 2026 at 10:56 AM Calvin Buckley <[email protected]> wrote:
> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args
>
> Have you done any benchmarking on this? What is the performance impact when
> it is enabled versus disabled? That information will be useful if this passes
> so that users can understand not just the security impact of having this
> information reported in logs, but the performance impact.
>
> --
> Matthew Weier O'Phinney
> [email protected]
> https://mwop.net/
> he/him
I've been doing a very stupid benchmark (let's call it Lhogstones):
<?php
/* -d error_include_args=X -d display_errors=0 -d error_log=/tmp/test */
$iter = isset($argv[1]) ? intval($argv[1]) : 10000;
$start = hrtime(true);
for ($i = 0; $i < $iter; $i++) {
hex2bin("ABC"); /* or like unlink("/") for something that does more */
}
$end = hrtime(true);
$total_ns = $end - $start;
$total = $total_ns / 1_000_000_000;
echo "Finished $iter iterations in $total sec\n";
?>
On an M1 Pro:
Iterations With Without
10000 0.025276917 0.016741333
100000 0.189566666 0.123559584
1000000 1.798127917 1.146331917
10000000 18.1332335 11.267384125
There is an impact from turning it on, but my feeling is that it would be
pretty minor. If your code has a lot of warnings/errors, then my feeling is
that errors should be fixed before you can or should measure performance.
Calling php_error_docref in a tight loop isn't really normal behaviour. So,
while there is an impact, I also don't think it matters too much. If people
think the impact *does* matter and is significant, then I could add a vote to
separate the production vs. development INI value.
