`GlobalRuntimeState::$interpolatedVariables` is never reset, so long-running Antlers renders slow down without bound

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

Los mantenedores suelen responder en 1 día

@lazerg ya está trabajando en esto.

Desde el 7/11/2026.

  • #15815 de @lazerg — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
laravel, php
Área
backend, performance

Línea de trabajo

Read GlobalRuntimeState::resetGlobalState() and the append in DocumentParser.php (the issue gives line numbers for several branches). Check the existing runtime state reset tests, then verify that resetting clears interpolatedVariables and that repeated renders no longer accumulate entries. Issue #15815 is an open linked pull request, so check its status before starting.

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

Descripción

Bug description

DocumentParser appends to GlobalRuntimeState::$interpolatedVariables every time it parses a template with an interpolated region (DocumentParser.php line 1071 in 5.x, 1242 on master, 1462 in 6.39.0):

GlobalRuntimeState::$interpolatedVariables[] = $results[2];

Environment::getValue() then checks every StringValueNode in every condition against the whole list:

if (Str::contains($val->value, GlobalRuntimeState::$interpolatedVariables)) {

Nothing ever empties the list. GlobalRuntimeState::resetGlobalState(), called per request through StateManager::resetState() by the ClearState listener on RequestHandled and ResponseCreated, resets every other piece of runtime state (templateFileStack, yieldStacks, layoutVariables and so on) but not $interpolatedVariables.

Under PHP-FPM each request is a fresh process, so this goes unnoticed. In any long-lived process that renders many views (statamic/ssg with workers, queue workers rendering views, Octane), the list grows with every request and every condition gets slower.

Measured

Static site generation (statamic/ssg, --workers=4) of a ~3,900-page site, rendering in one PHP process:

  • The list grew by about 118 entries per page (about 95 unique), reaching 23,718 entries after 200 pages.
  • Mean render time per page rose from about 0.7s to 1.5 to 1.7s over 500 pages.
  • A sampling profile of early against late pages attributed the growth to Str::contains under Environment::getValue (about 56ms to 659ms per page).
  • Clearing the list after each request kept render time flat. 500 pages took 274s instead of 512s, and a full build roughly halved. Page output was byte-identical, apart from per-render uniqid() values.
How to reproduce

Render the same Antlers view many times in one process, with a template that has an interpolated tag parameter (for example {{ partial:card :title="{title}" }} or {{ link to="/x/{slug}" }}), and dispatch RequestHandled between renders as the HTTP kernel does. count(GlobalRuntimeState::$interpolatedVariables) grows on every iteration, and the cost of conditions grows with it.

Suggested fix

Clear it with the rest of the runtime state:

public static function resetGlobalState()
{
    self::$templateFileStack = [];
    // ...
    self::$interpolatedVariables = [];
    // ...
}

Optionally, de-duplicate on append, or store it as a set keyed by value, so even a single long request can't grow it with duplicates.

Environment
  • Statamic 5.73.22 (also unchanged in 5.74.7, 6.40.0 and master as of 2026-11-07)
  • statamic/ssg 3.1.1, Laravel 10, PHP 8.3
  • Antlers runtime parser ('version' => 'runtime')
Lenguaje dominante
PHP
Estrellas
4.9k
Forks
647
Merge medio
21 h 3 min
PR fusionados (30 d)
128

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 statamic/cms

Todos los issues de statamic/cms

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.