Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127268
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 2 May 2025 11:14:37 +0300
Message-ID: <CAMW7n8A7v_pi_Co7KwFGLfSnMNJYutcMmfbDrjF2UDEBytv0SQ@mail.gmail.com>
Subject: [PHP-DEV] Deferred backtrace generation algorithm.
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Good day, everyone.

In the neighboring thread Concept: Lightweight error channels, the
topic of exception performance was discussed.

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 mistaken).

I have a small idea on how to improve the situation in cases where
exceptions are caught and a backtrace isn't needed.

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).

Based on that, there are two possible implementations:

* Generate the backtrace at the moment the stack is freed

* Clone the stack frame when the stack is freed (this is roughly what
happens in Python)

This would require changes to the functions
`zend_vm_stack_free_extra_args_ex` and
`zend_vm_stack_free_extra_args`.

These functions could be used to either clone the stack frame or
generate the full/partial backtrace at the right moment.

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.

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.

Nuances:

* It=E2=80=99s more efficient to copy only the parts of the stack frame nee=
ded
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.

* When cloning the stack frame, the reference to the previous frame
should automatically be incremented.

At first glance, this algorithm doesn=E2=80=99t break backward compatibilit=
y
in any way and spreads out memory/CPU costs.

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.

Cloned call frames exist only once and can be shared across multiple except=
ions.

**What are the benefits?**

* The cost of throwing an exception that is caught and not used at the
top level is nearly equivalent to a return operation.

* Lower memory usage when no backtrace is generated.

* It becomes possible to reuse a single backtrace generation for
multiple exceptions that share common frames (needs further
consideration).

**Drawbacks:**

* Exiting a PHP function consumes CPU to copy ~100 bytes of memory.

* Increased code complexity in the exception/stack frame modules.

These conclusions were made mentally without writing actual code.
But perhaps someone will have something to add =E2=80=94 either in favor or=
 against.

---
Ed.