Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127269
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 02 May 2025 10:52:22 +0200
To: internals@lists.php.net
Message-ID: <c5525d2a-ba32-4710-9f0e-13eb4501f059@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8A7v_pi_Co7KwFGLfSnMNJYutcMmfbDrjF2UDEBytv0SQ@mail.gmail.com>
References: 
 <CAMW7n8A7v_pi_Co7KwFGLfSnMNJYutcMmfbDrjF2UDEBytv0SQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Deferred backtrace generation algorithm.
Content-Type: multipart/alternative;
 boundary=22bc37cfe8104cec9ff05027ab6cd06e
From: rob@bottled.codes ("Rob Landers")

--22bc37cfe8104cec9ff05027ab6cd06e
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, May 2, 2025, at 10:14, Edmond Dantes wrote:
> Good day, everyone.
>=20
> In the neighboring thread Concept: Lightweight error channels, the
> topic of exception performance was discussed.
>=20
> The main issue is the immediate backtrace generation in the
> constructor, which can cause up to a 50% performance loss compared to
> return (as I understood from the discussion =E2=80=94 I may be mistake=
n).
>=20
> I have a small idea on how to improve the situation in cases where
> exceptions are caught and a backtrace isn't needed.
>=20
> Let=E2=80=99s assume we delay backtrace generation. In PHP, you can=E2=
=80=99t just
> keep a reference to a stack frame, since it may be destroyed. You
> could copy it, of course (which is relatively inexpensive compared to
> generating the full backtrace).
>=20
> Based on that, there are two possible implementations:
>=20
> * Generate the backtrace at the moment the stack is freed
>=20
> * Clone the stack frame when the stack is freed (this is roughly what
> happens in Python)
>=20
> This would require changes to the functions
> `zend_vm_stack_free_extra_args_ex` and
> `zend_vm_stack_free_extra_args`.
>=20
> These functions could be used to either clone the stack frame or
> generate the full/partial backtrace at the right moment.
>=20
> The information about whether something is referencing a stack frame
> could be stored in a separate structure in `EG`, so there would be no
> need to modify `zend_execute_data`.
> Any code referencing the frame would, of course, need to correctly
> decrement the reference counter.
>=20
> For example, when an exception is created, it increments the reference
> count on the current call frame, which guarantees that the frame stays
> available until either the exception is destroyed or the backtrace is
> generated.
>=20
> Nuances:
>=20
> * It=E2=80=99s more efficient to copy only the parts of the stack fram=
e needed
> for the backtrace, not the entire frame. This also applies to
> parameter slots =E2=80=94 they should be converted immediately if the
> DEBUG_BACKTRACE_IGNORE_ARGS flag is not set.
>=20
> * When cloning the stack frame, the reference to the previous frame
> should automatically be incremented.
>=20
> At first glance, this algorithm doesn=E2=80=99t break backward compati=
bility
> in any way and spreads out memory/CPU costs.
>=20
> Even if multiple exceptions are created within a function but no
> backtrace is generated, overall memory usage decreases, since Zend
> only retains the data structures currently needed, rather than
> duplicating them in each backtrace.
>=20
> Cloned call frames exist only once and can be shared across multiple e=
xceptions.
>=20
> **What are the benefits?**
>=20
> * The cost of throwing an exception that is caught and not used at the
> top level is nearly equivalent to a return operation.
>=20
> * Lower memory usage when no backtrace is generated.
>=20
> * It becomes possible to reuse a single backtrace generation for
> multiple exceptions that share common frames (needs further
> consideration).
>=20
> **Drawbacks:**
>=20
> * Exiting a PHP function consumes CPU to copy ~100 bytes of memory.
>=20
> * Increased code complexity in the exception/stack frame modules.
>=20
> These conclusions were made mentally without writing actual code.
> But perhaps someone will have something to add =E2=80=94 either in fav=
or or against.
>=20
> ---
> Ed.
>=20

Hey Ed,

> The main issue is the immediate backtrace generation in the
> constructor, which can cause up to a 50% performance loss compared to
> return (as I understood from the discussion =E2=80=94 I may be mistake=
n).

For what it is worth, the stack trace is not generated in the constructo=
r (at least from the perspective of the developer). Using reflection to =
create the exception without calling the constructor still results in th=
e stack trace being generated in the exception object. If it were create=
d only in the constructor, then I suspect this could all be resolved in =
user-land libraries.

=E2=80=94 Rob
--22bc37cfe8104cec9ff05027ab6cd06e
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Fri, May =
2, 2025, at 10:14, Edmond Dantes wrote:</div><blockquote type=3D"cite" i=
d=3D"qt" style=3D""><div>Good day, everyone.</div><div><br></div><div>In=
 the neighboring thread Concept: Lightweight error channels, the</div><d=
iv>topic of exception performance was discussed.</div><div><br></div><di=
v>The main issue is the immediate backtrace generation in the</div><div>=
constructor, which can cause up to a 50% performance loss compared to</d=
iv><div>return (as I understood from the discussion =E2=80=94 I may be m=
istaken).</div><div><br></div><div>I have a small idea on how to improve=
 the situation in cases where</div><div>exceptions are caught and a back=
trace isn't needed.</div><div><br></div><div>Let=E2=80=99s assume we del=
ay backtrace generation. In PHP, you can=E2=80=99t just</div><div>keep a=
 reference to a stack frame, since it may be destroyed. You</div><div>co=
uld copy it, of course (which is relatively inexpensive compared to</div=
><div>generating the full backtrace).</div><div><br></div><div>Based on =
that, there are two possible implementations:</div><div><br></div><div>*=
 Generate the backtrace at the moment the stack is freed</div><div><br><=
/div><div>* Clone the stack frame when the stack is freed (this is rough=
ly what</div><div>happens in Python)</div><div><br></div><div>This would=
 require changes to the functions</div><div>`zend_vm_stack_free_extra_ar=
gs_ex` and</div><div>`zend_vm_stack_free_extra_args`.</div><div><br></di=
v><div>These functions could be used to either clone the stack frame or<=
/div><div>generate the full/partial backtrace at the right moment.</div>=
<div><br></div><div>The information about whether something is referenci=
ng a stack frame</div><div>could be stored in a separate structure in `E=
G`, so there would be no</div><div>need to modify `zend_execute_data`.</=
div><div>Any code referencing the frame would, of course, need to correc=
tly</div><div>decrement the reference counter.</div><div><br></div><div>=
For example, when an exception is created, it increments the reference</=
div><div>count on the current call frame, which guarantees that the fram=
e stays</div><div>available until either the exception is destroyed or t=
he backtrace is</div><div>generated.</div><div><br></div><div>Nuances:</=
div><div><br></div><div>* It=E2=80=99s more efficient to copy only the p=
arts of the stack frame needed</div><div>for the backtrace, not the enti=
re frame. This also applies to</div><div>parameter slots =E2=80=94 they =
should be converted immediately if the</div><div>DEBUG_BACKTRACE_IGNORE_=
ARGS flag is not set.</div><div><br></div><div>* When cloning the stack =
frame, the reference to the previous frame</div><div>should automaticall=
y be incremented.</div><div><br></div><div>At first glance, this algorit=
hm doesn=E2=80=99t break backward compatibility</div><div>in any way and=
 spreads out memory/CPU costs.</div><div><br></div><div>Even if multiple=
 exceptions are created within a function but no</div><div>backtrace is =
generated, overall memory usage decreases, since Zend</div><div>only ret=
ains the data structures currently needed, rather than</div><div>duplica=
ting them in each backtrace.</div><div><br></div><div>Cloned call frames=
 exist only once and can be shared across multiple exceptions.</div><div=
><br></div><div>**What are the benefits?**</div><div><br></div><div>* Th=
e cost of throwing an exception that is caught and not used at the</div>=
<div>top level is nearly equivalent to a return operation.</div><div><br=
></div><div>* Lower memory usage when no backtrace is generated.</div><d=
iv><br></div><div>* It becomes possible to reuse a single backtrace gene=
ration for</div><div>multiple exceptions that share common frames (needs=
 further</div><div>consideration).</div><div><br></div><div>**Drawbacks:=
**</div><div><br></div><div>* Exiting a PHP function consumes CPU to cop=
y ~100 bytes of memory.</div><div><br></div><div>* Increased code comple=
xity in the exception/stack frame modules.</div><div><br></div><div>Thes=
e conclusions were made mentally without writing actual code.</div><div>=
But perhaps someone will have something to add =E2=80=94 either in favor=
 or against.</div><div><br></div><div>---</div><div>Ed.</div><div><br></=
div></blockquote><div><br></div><div>Hey Ed,</div><div><br></div><blockq=
uote type=3D"cite" id=3D"qt" style=3D""><div>The main issue is the immed=
iate backtrace generation in the</div><div>constructor, which can cause =
up to a 50% performance loss compared to</div><div>return (as I understo=
od from the discussion =E2=80=94 I may be mistaken).</div></blockquote><=
div><br></div><div>For what it is worth, the stack trace is not generate=
d in the constructor (at least from the perspective of the developer). U=
sing reflection to create the exception without calling the constructor =
still results in the stack trace being generated in the exception object=
. If it were created only in the constructor, then I suspect this could =
all be resolved in user-land libraries.<br></div><div><br></div><div id=3D=
"sig121229152">=E2=80=94 Rob</div></body></html>
--22bc37cfe8104cec9ff05027ab6cd06e--