Agenda - [PERF] Runtime Telemetry Hot Path

Problema

O runtime cobra telemetria de asset bank no caminho quente de todo host tick.

Hoje, tick() consulta bank_info() para gfx e audio mesmo quando nenhum logical frame foi fechado. O custo de observabilidade acaba sendo pago continuamente pela execucao normal.

Dor

CPU e locks sao gastos em todos os ticks, nao apenas quando a metrica muda.
hardware barato sofre mais com trabalho pequeno e repetitivo do que com picos raros.
overlay, stats e certifier acabam puxando custo estrutural para o core do runtime.

Hotspots Atuais

Alvo da Discussao

Remover varredura e agregacao lock-heavy do hot path do tick sem perder observabilidade util.

O Que Precisa Ser Definido

Modelo de metrica. Decidir o que passa a ser contador incremental e o que continua sendo snapshot sob demanda.
Frequencia de coleta. Decidir se atualizacao acontece:
- no fechamento do logical frame;
- apenas com overlay/debug ativo;
- por amostragem periodica;
- por evento de mutacao (load, commit, cancel).
Responsabilidade da agregacao. Delimitar se a verdade dos bytes/slots fica:
- no AssetManager;
- no runtime;
- em uma camada propria de telemetry cache.
Garantia de consistencia. Decidir qual grau de defasagem e aceitavel para handheld barato:
- exato em tempo real;
- eventual por frame;
- eventual por tick de debug.

Open Questions de Arquitetura

O certifier realmente precisa de snapshot de bank a cada tick?
O overlay pode ler uma versao resumida da telemetria em vez de recalcular tudo?
Vale manter caminho "preciso" so para testes/debug e caminho "barato" para runtime normal?

Dependencias

../specs/10-debug-inspection-and-profiling.md
../specs/16a-syscall-policies.md

Criterio de Saida Desta Agenda

Pode virar PR quando houver decisao escrita sobre:

metrica incremental vs snapshot;
ponto canonico de atualizacao da telemetria;
custo maximo aceitavel no hot path do tick;
comportamento de overlay/certifier sobre dados defasados.

2.4 KiB Raw Blame History