Quando os dados estão espalhados pela memória, a CPU precisa ir até a RAM, que é lenta, e esperar a cada acesso.
Por quê Objetos ligados por ponteiros, espalhados pela memória e acessados sem ordem → Efeito Como os dados não estão no cache da CPU, cada leitura vai à RAM (cerca de 100 vezes mais lenta) → Na tela O mesmo trabalho custa várias vezes mais tempo de tick; nos casos graves, câmera lenta
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Dispor em sequência na memória os dados usados juntos com frequência (design orientado a dados).
No gráfico
Sempre alto desde o início · Tempo de tick, uso de CPU
Onde olhar
Rodar perf stat -d -p PID no processo do servidor do jogo para medir instruções por ciclo (insn per cycle) e cache misses de L1 e LLC, e comparar com o tempo de tick e o uso de CPU
Confirma se
A CPU fica ocupada o tempo todo, mas o insn per cycle é baixo e há muitos misses de LLC. Confirmado se um build com outra disposição dos dados reduz muito o tempo de tick com o mesmo número de jogadores
Descarta se
CPU com uso baixo, mas tick lento: causa que espera fora da CPU, como lock ou espera de I/O
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
perf-stat(1) — Linux manual pageperf -p conta os eventos de hardware de um processo em execução e mostra o insn per cycle; -d adiciona os eventos de cache de dados L1 e LLC