Test de vitesse mémoire

Test de vitesse mémoire - Analysez votre RAM

Mesurez les performances RAM via plusieurs scénarios : tableaux, objets, chaînes, typed arrays et allocations massives. Idéal pour détecter les lenteurs et estimer l'efficacité mémoire côté navigateur.

Comment fonctionne le test de vitesse mémoire ?

Le test mesure les performances RAM en exécutant différentes opérations :

1. Tableaux : teste lecture/écriture sur tableaux standard (10 000 éléments)
2. Allocation d'objets : mesure création et modification (1 000 objets)
3. Chaînes : évalue concaténation, découpe et remplacement
4. Typed arrays : teste les données binaires (Int32, Float64, Uint8)
5. Allocation mémoire : mesure l'efficacité d'allocations massives

Chaque test tourne pour une durée fixe et calcule le nombre d'opérations par seconde. Plus d'ops/s = meilleures performances. L'outil utilise performance.now() pour une précision sub-milliseconde.

Quels facteurs influencent la vitesse mémoire ?

Plusieurs facteurs influencent les résultats :

- Quantité de RAM : plus de RAM permet de plus gros working sets sans swap
- Fréquence RAM : MHz plus élevés (3200, 4800, 6400 MT/s) = accès plus rapide
- Type de RAM : DDR5 > DDR4 > DDR3 (bande passante doublée à chaque génération)
- Cache CPU : tailles L1/L2/L3 influent sur les motifs d'accès
- Canaux mémoire : dual/quad channel double ou quadruple la bande passante
- Limites du navigateur : plafonds heap V8/SpiderMonkey (typiquement 2-4 Go)
- Processus en arrière-plan : autres applis qui consomment de la RAM déclenchent le swap
- Système d'exploitation : efficacité de gestion mémoire (Linux > Windows pour grosses allocations)

Pour des résultats fiables, fermez les applis gourmandes.

Qu'est-ce qu'un bon score de vitesse mémoire ?

Interprétation des résultats :

- Plus d'opérations/seconde = meilleures performances
- Moins de temps = exécution plus rapide

Scores typiques par tier :
- PC haut de gamme (32 Go+ DDR5-6400) : 50-100+ ops/s
- PC milieu de gamme (16 Go DDR4-3200) : 30-50 ops/s
- PC entrée de gamme (8 Go DDR4-2400) : 15-30 ops/s
- Ordinateurs portables modernes : 10-40 ops/s
- Mobile/tablettes : 5-15 ops/s

Note : les scores varient selon le navigateur et l'optimisation du moteur JavaScript (V8 vs SpiderMonkey vs JavaScriptCore).

Pourquoi tester la mémoire dans le navigateur ?

Avantages des tests mémoire en ligne :

- Aucune installation : testez immédiatement, sans téléchargement
- Multi-plateforme : fonctionne sur tout OS avec navigateur
- Sûr : exécuté en sandbox, sans risque pour le système
- Diagnostic rapide : identifiez vite les goulots mémoire
- Performance web : voyez comment les web apps tourneront

Moins exhaustif qu'un MemTest86 ou AIDA64, mais idéal pour juger les performances mémoire JavaScript, ce qui compte pour les web apps, Node.js et charges en navigateur.

Qu'est-ce que le heap JavaScript et pourquoi limite-t-il les tests ?

Le heap JavaScript est la région mémoire dédiée où le moteur JS (V8, SpiderMonkey, JavaScriptCore) alloue objets, tableaux et chaînes. Les navigateurs plafonnent le heap pour éviter les pages incontrôlables : Chrome desktop ~4 Go, Firefox ~2 Go, Chrome mobile ~256-512 Mo, Safari iOS ~384 Mo. Si un test demande plus de mémoire que le plafond, le moteur lance RangeError ou déclenche un ramasse-miettes qui fausse les temps. window.performance.memory (Chromium uniquement) expose jsHeapSizeLimit, totalJSHeapSize et usedJSHeapSize pour voir à quel point vous frôlez la limite.

Pourquoi les typed arrays sont-ils plus rapides que les tableaux standards ?

Les tableaux JS standards stockent des valeurs boxées : chaque élément contient un pointeur plus un tag float64, même pour les entiers. Les typed arrays (Int32Array, Float64Array, Uint8Array) stockent des données binaires brutes dans un ArrayBuffer contigu sans boxing. Lire l'élément i lit directement les octets [i*4 .. i*4+3], comme en C. Cela évite le ramasse-miettes, esquive les transitions de hidden class et permet au JIT d'émettre des instructions SIMD. Résultat : les typed arrays sont 2-5x plus rapides pour les calculs numériques et utilisent 4-8x moins de mémoire.

Que signifie réellement le chiffre de heap utilisé ?

window.performance.memory.usedJSHeapSize indique combien d'octets le ramasse-miettes V8 considère accessibles via les objets racine de la page. Ça exclut les nœuds DOM détachés en attente de balayage, les buffers natifs (les stores des ArrayBuffer vivent hors du heap JS) et les données de cache inline. Les chiffres bondissent quand le GC tourne (toutes les 50-200ms en charge) et la valeur est arrondie au 100 Ko le plus proche pour la confidentialité (atténue les attaques de timing type Spectre). Firefox et Safari n'exposent pas cette API pour la même raison.

Pourquoi le test ralentit-il aux exécutions suivantes ?

Trois effets se cumulent :

1. Arriéré du GC : chaque exécution laisse des objets à collecter ; la seconde paye le nettoyage de la première.
2. Fragmentation du heap : les cycles répétés allocation/libération créent des trous que l'allocateur doit parcourir, augmentant la latence.
3. Throttling thermique : une activité CPU+RAM soutenue pendant 30 s ou plus fait monter la température du silicium au-dessus de TJMax (~100 °C), à partir de quoi CPU/contrôleur mémoire baissent leur fréquence de 10-30 % pour éviter les dommages.

Pour repartir sur une base stable, cliquez sur Réinitialiser, attendez 10 secondes pour le GC et le refroidissement, puis relancez.

Fonctionnalités

• 5 tests mémoire complémentaires
• Mesure en direct des opérations/seconde
• Benchmarks tableaux, objets, chaînes, typed arrays
• Test d'allocations massives
• Affichage des infos heap/limites
• Score global et détail par test
• Indicateurs de progression
• Arrêt à tout moment
• Réinitialisation rapide
• 100 % côté client, mode hors ligne
• Compatible mobile/desktop
• Mode sombre pris en charge