[performance] Лимит 12 пожаров не ограничивает число активных эффектов при массовом ударе #69

New Issue

2026-10-29T21:12:22Z

chexit commented

2026-10-29 21:12:22 +00:00

🤖 Filed by Codex, AI-агент Владимира (chexit).

Ревью 6f3fc644bc5194311a86baba722bc340215306b7. Новая система пожаров #52 имеет мягкий fade, но не bounded бюджет активных эффектов. Во время массового удара это отдельный источник просадок CPU/WASM, particle output и lights.

Причина

sim/fires.rs::ignite всегда добавляет Fire. Если list.len()>MAX, только одному старому пожару сокращается life до age+160. Его не убирают из списка/из отрисовки и не снижают текущий уровень огня. При одновременных попаданиях age=0 и life=160; level первые 45% этого срока оставляет обычные сильные flames. step_fires, lib.rs::lights и вывод частиц продолжают проходить по всем таким fires, пока не истекут 8 секунд.

Штатный fires_start_merge_and_are_limited проверяет только число fires с большим остатком life, не число отображаемых пожаров, частиц и lights.

Выполненное воспроизведение

100 вызовов ignite в один тик, точки разнесены на 10 блоков (не merge); через 40 тиков:

fires=100, strong_flames=100, advertised_MAX=12

Это нативный тест реальных ignite/step_fires, damage=false. GPU-время здесь не измерялось: доказано превышение заявленного бюджета, не конкретное падение FPS.

Нужно

Развести логические места пожаров и жёсткий бюджет визуализации/реальных fire-block команд. Ограничить число fade-out slots либо агрегировать дальние/близкие пожары; плавно перераспределять качество и приоритеты без сотен одновременных полноценных эффектов. Не возвращать прежнюю проблему взрывов/ракет, теряющих критические эффекты из-за общей .take очереди. Задать понятный максимум list/particles/lights и учитывать replay.

Приёмка

100 и более одновременных пространственно разнесённых попаданий, повторные удары и длительный поток; реальный верхний предел стоимости и памяти, отсечение вдали, корректное завершение и очистка fire-blocks. Профиль GPU/CPU на Mac до/после без молчаливого отключения всей сцены.

🤖 Filed by Codex, AI-агент Владимира (chexit). Ревью `6f3fc644bc5194311a86baba722bc340215306b7`. Новая система пожаров #52 имеет мягкий fade, но не bounded бюджет активных эффектов. Во время массового удара это отдельный источник просадок CPU/WASM, particle output и lights. ### Причина `sim/fires.rs::ignite` всегда добавляет Fire. Если `list.len()>MAX`, только одному старому пожару сокращается `life` до age+160. Его не убирают из списка/из отрисовки и не снижают текущий уровень огня. При одновременных попаданиях age=0 и life=160; `level` первые 45% этого срока оставляет обычные сильные flames. `step_fires`, `lib.rs::lights` и вывод частиц продолжают проходить по всем таким fires, пока не истекут 8 секунд. Штатный `fires_start_merge_and_are_limited` проверяет только число fires с большим остатком life, не число отображаемых пожаров, частиц и lights. ### Выполненное воспроизведение 100 вызовов ignite в один тик, точки разнесены на 10 блоков (не merge); через 40 тиков: ```text fires=100, strong_flames=100, advertised_MAX=12 ``` Это нативный тест реальных ignite/step_fires, `damage=false`. GPU-время здесь не измерялось: доказано превышение заявленного бюджета, не конкретное падение FPS. ### Нужно Развести логические места пожаров и жёсткий бюджет визуализации/реальных fire-block команд. Ограничить число fade-out slots либо агрегировать дальние/близкие пожары; плавно перераспределять качество и приоритеты без сотен одновременных полноценных эффектов. Не возвращать прежнюю проблему взрывов/ракет, теряющих критические эффекты из-за общей `.take` очереди. Задать понятный максимум list/particles/lights и учитывать replay. ### Приёмка 100 и более одновременных пространственно разнесённых попаданий, повторные удары и длительный поток; реальный верхний предел стоимости и памяти, отсечение вдали, корректное завершение и очистка fire-blocks. Профиль GPU/CPU на Mac до/после без молчаливого отключения всей сцены.