CPU performance et profiling

Profiling basics

Une frame dispose de 16,67 ms à 60 Hz

À 60 Hz, le navigateur doit produire une nouvelle frame environ toutes les 16,67 ms. Nous pouvons chronométrer le travail JavaScript de la simulation et du rendu, puis le comparer à ce frame budget.

const FRAME_BUDGET_MS = 1000 / 60;

const averageSceneWorkTime = this.totalSceneWorkTime / this.frameCount;

this.snapshot = {
  sceneBudgetUsed: (averageSceneWorkTime / FRAME_BUDGET_MS) * 100
};

Cette mesure porte uniquement sur le bloc entouré par les deux appels à performance.now(). Elle ne représente ni l’utilisation CPU totale du navigateur, ni tout le travail nécessaire pour afficher la frame. Dans le lab, nous prenons une moyenne sur plusieurs frames pour éviter de surinterpréter un pic isolé.

Première trace dans Performance

Ouvrez les DevTools, puis passez à l’onglet Performance.

1. Choisissez une interaction courte et reproductible.
2. Dans Performance, lancez Record, exécutez cette interaction, puis arrêtez l’enregistrement.
3. Tentez d’interpréter le résultat.
4. Utilisez Bottom-Up pour trouver les fonctions coûteuses et Call Tree pour comprendre comment elles ont été appelées.

Le frame budget signale qu’une frame est en danger. La trace Performance explique où le temps a été dépensé.

Provoquer une frame lente

Déclenchez l’attaque spéciale

Lancez un enregistrement, puis appuyez simultanément sur O pour recharger le condensateur et sur X pour déclencher l’attaque spéciale. La salve crée 30 particles dans la même frame : recommencez plusieurs fois pour rendre le pic bien visible.

Retenez surtout l’approche visuelle : les vignettes montrent l’état exact de chaque frame enregistrée, les pistes distinguent le travail du thread principal et du GPU, et Bottom-Up indique quelles fonctions prennent du temps, comme drawImage ici.

Rendre le pic immanquable

100× les particules d’une mine

Pour obtenir un pic nettement plus grand, le lab multiplie par 100 les 32 débris d’une mine détruite. Lancez une trace, détruisez une mine, puis observez la frame qui suit : elle crée 3 200 particles physiques d’un coup.

emitExplosion(x, y) {
  this.explosionFlash.emitParticleAt(x, y);
  const particleCount = EXPLOSIONS.particlesPerMine * 100;

  for (let index = 0; index < particleCount; index += 1) {
    const particle = new ExplosionParticle(this);
    this.explosionDebris.add(particle);
    particle.explode(x, y);
  }
}

Bingo

Cette explosion pousse le rendu et le traitement de la frame au-delà des 16,67 ms : ici, elle monte à environ 24 ms. Vous pouvez maintenant croiser ce constat avec les autres techniques de debugging pour vous entraîner sur les prochains cas. Aujourd’hui, l’objectif était simplement de le voir en action.

Essayez. Explorez, bidouillez, faites planter le navigateur avec des quantités absurdes de particles. Ou jouez, tout simplement. Vous vouliez une session de debugging avancé et des jeux vidéo ? Vous avez les deux. Heureux ? #ThatsWhatSheSaid

C’est volontairement excessif. Comme les débris ne sont pas détruits dans cette version du lab, rechargez la page après la trace avant de recommencer.

Simuler une machine moins rapide

Ralentissez le CPU

Dans les réglages d’environnement de Performance, le menu CPU permet de simuler une machine moins rapide. Réglez-le sur 20× slowdown, puis rejouez la même courte trace : les problèmes plus discrets ressortent alors plus facilement.

Sur une machine moderne, le lab fait de son mieux pour rendre ce ralentissement visible : il utilise volontairement le renderer Canvas de Phaser plutôt que WebGL. Cela limite autant que possible le travail confié au GPU, afin que le coût de dessin ressorte dans la trace CPU.