Comment Firefox a-t-il optimisé cette boucle ?

Question

Firefox 9.0.1 m'a surpris en faisant apparaître mon algorithme de remplissage de nombres (log n) avec une méthode à (n) boucles lorsque n est petit. Dans tous les autres navigateurs que j'ai vus, la boucle est plus lente. Je sais que tous les navigateurs travaillent à l'optimisation des JS, mais puisque tous les autres navigateurs modernes montrent que la boucle est plus lente, y a-t-il une explication à ce comportement dans Firefox 9 ?

// (log n)
function padNumberMath(number, length) {
    var N = Math.pow(10, length);
    return number < N ? ("" + (N + number)).slice(1) : "" + number
}

// (n):
function padNumberLoop(number, length) {
    var my_string = '' + number;
    while (my_string.length < length) {
        my_string = '0' + my_string;
    }
    return my_string;
}

Mise à jour : Je ne pense pas que cela soit lié à la question initiale, mais je viens de découvrir qu'IE 9 change de comportement lorsqu'il passe du mode 32 bits au mode 64 bits. En mode 32 bits, c'est la méthode Math qui l'emporte. En mode 64 bits, c'est la méthode Loop qui l'emporte. J'ai juste pensé que je devais le signaler.

Mise à jour 2 : MAK m'a surpris dans son commentaire ci-dessous. La méthode mathématique n'est pas (1), c'est probablement plus comme (log n).

Answer 1

Regarder les résultats il est assez clair que Firefox n'a pas fait tout ce qui est pour réaliser une performance gain .

Ces barres peuvent être lues comme des "vitesses" (opérations/sec), les plus grandes barres sont donc préférables. . Tout est à l'échelle.

Dans Firefox 9, il est très clair que la méthode "Math" donne des résultats catastrophiques, alors que la méthode "Loop" n'a guère changé entre les versions.

Il y avait donc pas de "optimisation" de toute sorte dans Firefox 9. Tout ce qui s'est passé entre Firefox 8 et 9 en ce qui concerne ces tests, c'est que leur bibliothèque mathématique est devenue plus lente ( Math.pow étant lent), ou leur bibliothèque de chaînes de caractères est devenue plus lente ( .slice() être lent).

En y regardant de plus près, il est clair d'une certaine manière, ces opérations élémentaires sont devenues un peu plus lentes dans ff9 :

La concaténation et Math.pow sont tous deux un peu plus lents dans FF 9 que dans FF 8, ce qui peut expliquer la différence que vous constatez dans vos tests.

Il est intéressant de noter que la nouvelle barre d'interdiction est beaucoup plus longue dans FF8 que dans FF9.

Answer 2

Cela pourrait être aussi rapide que de copier la chaîne de paramètres dans un nouveau tableau de caractères, qui sont peut-être par défaut initialisés à un caractère pertinent, dans ce cas un chiffre.

Peut-être que le fait de reconnaître l'affectation récursive qui implique une constante permet une concaténation rapide d'une chaîne de longueur-mystring.longueur+1 '0' avec mystring.

Il peut aussi s'agir d'un problème aussi simple que l'exponentiation de Firefox qui devient plus lente en n'utilisant pas l'expansion binaire de l'exposant pour l'élévation au carré répétée.

Answer 3

Firefox 9.0.1 m'a surpris en faisant apparaître mon algorithme Ω(1) de bourrage de chiffres avec une méthode de boucle Ω(n) lorsque n est petit.

N'y a-t-il pas des parties manquantes dans cette phrase ? Elle s'affichait comme être plus rapide ou quelque chose comme ça ? Et pourquoi concatènes-tu des fichiers vides String s à Number s ? Pourquoi ne pas simplement construire un String ?

Et oui, votre O(1) est en réalité O(log)...

Quoi qu'il en soit, l'explication est probablement due à Inférence de type dans Firefox 9