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

オープン
#15,814 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@lazerg がすでに取り組んでいます。

2026年11月7日 から。

  • #15815 @lazerg による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
laravel, php

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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')
主要言語
PHP
スター
4.9k
フォーク
647
平均マージ
21時間 3分
マージ済み PR(30日)
128

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

statamic/cms のほかの issue

statamic/cms の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。