Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:130592 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 85CC21A00BC for ; Wed, 8 Apr 2026 22:09:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1775686147; bh=qA1QlLuJ7XcW3MENXQzQlmCB+iyWfKI5MK819XJVGCk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Iyv3drr26ocqwOnPEyB5hmCmn4TFjoOs/eXn5ACWvYW//TdSggvjM0dWwkEe+xRkP sWNka4/yHaivQvmco3bsKchBPXN4+yK2ybII3BKUMesvXIA4P231MQ5OzMrYDf7gN6 tuz3K/+gAbFbYXM8O9RYkmom/gomfNrAa0G8MzKjUNnutjdRnE1D8n6nshacAE+w/L xa/8TiBfXyL3Ds4RQXrl7ZZpmyk0FPVnv9OzHTcVrO9m+PZIwFxkq74LPvhB3vkYxS VnvhGbkGbkHdrm0Sy+YTQGmEYdE4bQv0gKlhgGEzYZEUK2IGXz0vd9OU3QOaVgrv1N Lsslc+hDhz+IA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 192C4180077 for ; Wed, 8 Apr 2026 22:09:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DMARC_MISSING, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from supercat.cmpct.info (supercat.cmpct.info [71.19.146.230]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 8 Apr 2026 22:09:03 +0000 (UTC) Received: from smtpclient.apple (fctnnbsc38w-142-134-101-31.dhcp-dynamic.fibreop.nb.bellaliant.net [142.134.101.31]) by supercat.cmpct.info (Postfix) with ESMTPSA id 3CCD34325F; Wed, 08 Apr 2026 22:08:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\)) Subject: Re: [PHP-DEV] [RFC] Display Function Arguments in Errors In-Reply-To: Date: Wed, 8 Apr 2026 19:08:44 -0300 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <939CFA28-A6FF-433F-85A0-B83345CEF4A6@cmpct.info> To: Matthew Weier O'Phinney X-Mailer: Apple Mail (2.3864.500.181) From: calvin@cmpct.info (Calvin Buckley) On Apr 2, 2026, at 11:25=E2=80=AFAM, Matthew Weier O'Phinney = wrote: >=20 > On Wed, Mar 11, 2026 at 10:56=E2=80=AFAM Calvin Buckley = 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. >=20 > https://wiki.php.net/rfc/display_error_function_args >=20 > 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. >=20 > --=20 > Matthew Weier O'Phinney > mweierophinney@gmail.com > https://mwop.net/ > he/him I've been doing a very stupid benchmark (let's call it Lhogstones): 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.=