Performance: rewrite only the `new` expressions an `initialization(...)` pointcut can match

Abierto
  • ¿Algo no está bien?
#833 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php
Área
backend, performance

Línea de trabajo

Start with ConstructorExecutionTransformer and its $sourceMarkers logic, then trace how AdvisorIndex represents initialization pointcut class filters and how woven files track aspect and kernel resources. Add focused transformer tests for unrelated, matching, subclass, non-reducible, and dynamic new expressions; done means unrelated classes remain native while the existing initialization tests still pass. Compare transformation performance on a woven file with many unrelated constructions before and after.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Enhancement Performance

Split from #818, part 3 (the optional transformer prefilter). Parts 1–2 shipped in #828.

Problem

While at least one initialization(...) pointcut is registered, ConstructorExecutionTransformer rewrites every new Foo(...) in every woven file into ConstructorExecutionTransformer::construct(...). The rule is all-or-nothing: $sourceMarkers returns ['new'] as soon as AdvisorIndex::hasPointcutKind(Pointcut::KIND_INIT) is true. One initialization(App\Domain\Order) pointcut is enough to route the new of every class in the application through the transformer.

#828 made the runtime side cheaper: the per-class strategy cache, and a native new for instantiable classes without initialization advices. The remaining cost is still there for every rewritten new of an unrelated class.

new of a class no pointcut matches ns per new (PHP 8.5, JIT off)
native new ~64
rewritten, public constructor (after #828) ~193
rewritten, private/protected constructor, abstract, enum ~500 (still the advice-less ReflectionConstructorInvocation)

The rewrite also makes woven sources and stack traces noisier (an extra transformer frame per new).

Proposal

Rewrite only the new expressions whose class can match one of the registered initialization pointcuts, and keep the others native.

When the rewrite stays:

  • Resolve the class name of each new at transform time (the name resolver already runs).
  • Keep the rewrite for every new whose class can't be decided statically: new $class, new static, new self/new parent where the target is unknown, and anonymous classes as today.

Pointcut side: a small, conservative API.

  • The initialization class filters are namespace patterns: App\Domain\*, **, Foo|Bar.
  • A filter like Foo+ also matches subclasses and can't be decided by name. The same goes for an expression combined with other pointcuts in a way that can't be reduced to class-name patterns (!, && with within(...), references).
  • A pointcut of that kind answers "may match anything", and the transformer then keeps rewriting every new, as today.
  • Compare #747 and #821, which hit the same need for a name-part API.

Caching: the decision belongs to the woven file. A changed set of initialization pointcuts must re-weave affected files. Check that aspect and kernel changes already invalidate woven files through the tracked resources, the same way any advice change does.

Acceptance

  • With an unrelated initialization(...) pointcut registered, new of a class that can't match stays a native new in the woven source: snapshot or unit test on ConstructorExecutionTransformer.
  • Classes that can match, + subclass filters, non-reducible expressions and dynamic new keep the current rewrite, with identical behaviour in the existing initialization tests.
  • A benchmark of a woven file with many new of unrelated classes, before and after.
  • composer test, composer analyze, composer test:performance:transformation (the transformer changes, so CI compares head with base).

Scoring

Score Why
Effort Medium A pointcut-side "class name may match" API that is conservative for +, !, && and references, plus the per-new decision in the transformer, snapshot tests and the transformation-performance run. No runtime or format change.
Impact Low–Medium Applications without initialization(...) pointcuts gain nothing. With one, every new of an unrelated class saves ~130 ns, or ~430 ns for classes with a non-public constructor, abstract classes and enums, and woven sources lose the extra frame. It only matters for code that creates many objects in woven files.

Priority Low: #828 already removed most of the cost on the hot path.

Lenguaje dominante
PHP
Estrellas
1.7k
Forks
166
Merge medio
1 d 1 h
PR fusionados (30 d)
38

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de goaop/framework

Todos los issues de goaop/framework

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.