Si los datos están dispersos por la memoria, la CPU tiene que ir cada vez hasta la RAM, que es lenta, y esperar.
Por qué Objetos dispersos y enlazados por punteros, a los que se accede sin orden → Efecto Como no están en la caché de la CPU, se leen de la RAM cada vez (alrededor de 100 veces más lento) → En pantalla El mismo trabajo cuesta varias veces más tiempo de tick; en casos graves, cámara lenta
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Colocar de forma contigua los datos que se usan juntos a menudo (diseño orientado a datos).
En el gráfico
Siempre alto · Tiempo de tick, uso de CPU
Dónde mirar
Medir con perf stat -d -p PID sobre el proceso del servidor del juego las instrucciones por ciclo (insn per cycle) y los fallos de caché L1 y LLC, junto con el tiempo de tick y el uso de CPU
Se confirma si
La CPU está ocupada todo el tiempo, pero insn per cycle es bajo y hay muchos fallos de LLC. Se confirma si, en una build con otra disposición de los datos, el tiempo de tick con el mismo número de jugadores baja mucho
Se descarta si
Si el uso de CPU es bajo pero el tick va lento, apunta a esperas fuera de la CPU, como locks o E/S
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
perf-stat(1) — Linux manual pageperf -p cuenta los eventos de hardware de un proceso en ejecución y muestra insn per cycle; -d añade los eventos de la caché de datos L1 y LLC