Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127266
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [PHP-DEV] Concept: Lightweight error channels
In-Reply-To: <CAAKU0u=AjAiVYueHzOJB4yCbAW2ZiKMc+BvDKZeDQNk_pcjOpw@mail.gmail.com>
Date: Thu, 1 May 2025 10:57:59 -0500
Cc: Niels Dossche <dossche.niels@gmail.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <6D9C1AC0-1AA5-409F-AC07-2327922E1EB9@pmjones.io>
References: <39597a9c-6854-40c6-a529-32b2b178cb27@app.fastmail.com>
 <7bc87f46-7d5a-4848-b505-a77499281f45@gmail.com>
 <88839E7C-E41B-434F-B7D5-16240D64ABD3@pmjones.io>
 <CAAKU0u=AjAiVYueHzOJB4yCbAW2ZiKMc+BvDKZeDQNk_pcjOpw@mail.gmail.com>
To: Levi Morrison <levi.morrison@datadoghq.com>
From: pmjones@pmjones.io ("Paul M. Jones")

Hi all,

> On May 1, 2025, at 09:29, Levi Morrison <levi.morrison@datadoghq.com> =
wrote:
>=20
> On Tue, Apr 29, 2025 at 9:48=E2=80=AFAM Paul M. Jones =
<pmjones@pmjones.io> wrote:
>>=20
>>=20
>>=20
>>> On Apr 27, 2025, at 07:26, Niels Dossche <dossche.niels@gmail.com> =
wrote:
>>>=20
>>> Regarding performance however, rather than introducing yet another =
completely new concept to do almost the same thing, why not try to =
improve exception performance instead?
>>>=20
>>> I just opened a PR that makes instantiating exceptions much much =
faster, and this is only after like 15 mins of work. I'm sure there's =
even more to gain.
>>=20
>> I mean, squeeze out gains where you can where the effort:reward ratio =
is good, but the following is a naive but representative result on an =
MacBook M3 Pro:
>>=20
>> ```
>> return false    100000 times =3D 0.075289011001587
>> throw exception 100000 times =3D 0.11530804634094
>> ```
>>=20
>> Do we consider a difference of 0.075/100000s vs 0.115/100000s that =
big a deal when compared to (e.g.) establishing a database connection?
>=20
> The first part, the 0.075 vs 0.115... yeah, we care. That's 50%
> slower.=20

(/me nods along) A 50% increase in execution time, but a 50% increase in =
things that when all combined take up (e.g.) only 0.01% of the total =
execution time -- is *that* something we care about?

And "care about" relative to what else in comparison? Something like a =
starting a database connection might incur a much greater penalty, =
drowning out the exception penalty in total execution time.

But then again ...

> But the thing is, the math with exceptions is kind of [un]knowable
> because one of the key aspects of its cost is walking the call stack.
> How deep is the call stack going to be when a given library throws an
> exception? You don't really know.

[edited to include your note about the typo]

... yeah, that makes it tough to determine how much of a penalty there =
might be. How can we quantify that, if at all?

In any case, if there are performance gains to be squeezed out of the =
existing exceptions model (especially at a good effort:reward ratio) =
then of course that's something to pursue.


-- pmj