Plus de jeux sur WuGames.ioSponsoriséDécouvrez des jeux de navigateur gratuits — jouez aussitôt, sans téléchargement ni inscription.Jouer

Test de vitesse mémoire

Testez votre RAM : tableaux, allocations d'objets, chaînes, typed arrays. Mesurez les opérations/seconde et l'efficacité mémoire.

Infos mémoire
Rapporté par le navigateur, Chromium uniquement et arrondi (ex. : 32 Go s'affiche en 8 Go) — ce n'est pas la RAM réellement installée.

Tests mémoire
TestOpérations/sDuréeStatut
Tableaux
Création/lecture/écriture sur 10 000 éléments
-- En attente
Objets
Création/modification de 1 000 objets
-- En attente
Chaînes
Concaténation, découpe, remplacement
-- En attente
Typed arrays
Int32, Float64, Uint8
-- En attente
Allocation mémoire
Allocation/libération de blocs volumineux
-- En attente
Indice sans unité = moyenne géométrique de la médiane d'ops/s de chaque test (pas des ops/s ; combine équitablement des tests non comparables).

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.

Test de vitesse mémoire — Testez votre RAM : tableaux, allocations d'objets, chaînes, typed arrays. Mesurez les opérations/seconde et l'efficacité
Test de vitesse 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.

Quels navigateurs exposent performance.memory et navigator.deviceMemory ?

Seuls les navigateurs basés sur Chromium (Chrome, Edge, Opera, Brave) les exposent, et les deux sont non standard et dépréciés :

- performance.memory (jsHeapSizeLimit / totalJSHeapSize / usedJSHeapSize) : Chromium uniquement. Firefox et Safari ne l'implémentent pas volontairement pour bloquer les attaques de timing type Spectre. Les valeurs sont quantifiées (arrondies à ~100 Ko).
- navigator.deviceMemory : Chromium uniquement et quantifiée pour la confidentialité à l'une de {0,25, 0,5, 1, 2, 4, 8} Go. Une machine de 16 Go ou 32 Go signale toutes deux «8 Go» : c'est donc un indice approximatif du navigateur, PAS votre RAM installée.

Sur Firefox et Safari, la carte Infos mémoire affiche «Non pris en charge» pour ces champs : c'est attendu, pas un bug. Le benchmark (ops/s des tableaux, objets, chaînes, typed arrays et allocations) n'utilise que performance.now() et tourne à l'identique sur tous les navigateurs.

Est-ce sûr et privé ? Faut-il des autorisations ?

Oui. Le benchmark s'exécute à 100 % côté client dans votre onglet via du JavaScript ordinaire et performance.now(). Rien n'est envoyé, aucun compte, aucune demande d'autorisation ni exigence de contexte sécurisé (HTTPS) — il fonctionne hors ligne. L'export JSON/CSV optionnel est généré localement dans votre navigateur et enregistré directement sur votre appareil ; il n'est jamais envoyé à un serveur.

Comment lire les résultats pour un test QA pass/échec ?

Utilisez les statistiques multi-exécutions, pas un chiffre unique :

1. Réglez Itérations sur 5 ou 10 pour que chaque test produise un échantillon avec moyenne ± écart-type, médiane, min et max.
2. Jugez la stabilité avec le CV (coefficient de variation = écart-type/moyenne) : vert sous 5 % = reproductible ; jaune 5-15 % = limite (charge en arrière-plan ou léger throttling) ; rouge au-dessus de 15 % = instable, probablement throttling thermique ou pression GC — refaites sur une machine froide et inactive avant de certifier.
3. Comparez la médiane (robuste aux valeurs aberrantes) plutôt que la moyenne pour le pass/échec face à une référence connue.
4. L'Indice composite est une moyenne géométrique sans unité des cinq médianes — utilisez-le pour classer les appareils ; utilisez les médianes par test pour localiser une faiblesse.
5. Exportez en JSON/CSV pour joindre la session complète (horodatage, user agent, échantillons, stats, indice) à un ticket ou la comparer à un fichier de référence.

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
  • Échantillonnage multi-exécutions (1/3/5/10 itérations)
  • Min/max/moyenne/médiane et écart-type par test
  • Badge de stabilité de la variance (CV) entre exécutions
  • Indice composite par moyenne géométrique (pas de moyenne arithmétique trompeuse)
  • Export JSON et CSV du rapport de session complet
  • 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