Chrome pense que 99 999 est radicalement différent de 100 000.

Question

Je viens de rencontrer un problème très intéressant lorsque quelqu'un a posté un benchmark jsperf qui entrait en conflit avec un benchmark précédent, presque identique, que j'ai exécuté.

Chrome fait quelque chose radicalement différent entre ces deux lignes :

new Array(99999);  // jsperf ~50,000 ops/sec
new Array(100000); // jsperf ~1,700,000 ops/sec

points de repère : http://jsperf.com/newarrayassign/2

Je me demandais si quelqu'un avait la moindre idée de ce qui se passe ici !

(Pour clarifier, je cherche des détails de bas niveau sur les internes de V8, comme l'utilisation d'une structure de données différente avec l'un et l'autre et quelles sont ces structures).

Answer 1

Juste parce que cela semblait intéressant, j'ai cherché dans la base de code de V8 une statique définie comme 100000, et j'ai trouvé ce kInitialMaxFastElementArray var qui est ensuite utilisé dans le intégré ArrayConstructInitializeElements fonction fonction. Bien que je ne sois pas un programmeur c et que je ne connaisse pas les détails ici, vous pouvez voir qu'il utilise une fonction if boucle pour déterminer si elle est inférieure à 100 000, et return à différents moments en fonction de cela.

Answer 2

Eh bien, il y a toujours un certain nombre de seuils lorsque vous concevez des algorithmes qui s'adaptent à la taille des données (par exemple SharePoint modifie son mode de fonctionnement lorsque vous ajoutez 1000 éléments à une liste ). On peut donc supposer que vous avez trouvé le nombre réel et que les performances diffèrent, car différentes structures de données ou algorithmes sont utilisés.

Answer 3

Je ne sais pas quel système d'exploitation vous utilisez, mais s'il s'agit de Linux, je soupçonne que Chrome (c.-à-d. malloc ) alloue de la mémoire à partir d'un tas géré par le programme (taille déterminée à l'aide de la fonction sbrk et les listes libres sont gérées par la bibliothèque standard C), mais lorsque vous atteignez un certain seuil de taille, il bascule vers l'utilisation de mmap pour demander au noyau d'allouer de gros morceaux de mémoire qui n'interfèrent pas avec le système de gestion de l'information. sbrk -Le tas géré.

Doug Lea décrit comment malloc travaille dans la bibliothèque GNU C, mieux que je ne le pourrais. Il l'a écrit.

---

Ou peut-être que 100000 atteint une sorte de seuil magique pour la quantité d'espace nécessaire qui déclenche le ramasseur de déchets plus fréquemment lorsqu'il essaie d'allouer de la mémoire.