Sont ES6 modèle de littéraux plus vite que la concaténation de chaîne?

Quelqu'un a fait de repères? Je suis curieux de savoir si HTML de génération de code est plus rapide avec la concaténation de chaîne ou avec le modèle des littéraux dans le Nœud et les navigateurs modernes.

Par exemple:

De concaténation de chaîne

"<body>"+
  "<article>"+
    "<time datetime='" + date.toISOString() +"'>"+ date +"</time>"+
  "</article>"+
"</body>"

Modèle littérale

`<body>
  <article>
    <time datetime='${ date.toISOString() }'>${ date }</time>
  </article>
</body>`
  • La concaténation de chaîne n'est pas assez lent, qu'il est notable de la place pour de l'amélioration. populaire templaters comme moustache/souligner/guidon sont des dizaines voire des centaines de fois plus lent que la concaténation est ou le modèle de littéraux sera.
  • Théorique de parler (sauf si le JS est compilé), modèle de littéraux serait plus lent depuis la "chaîne" doit être analysée indépendamment de l'espace réservé à l'existence. La JS moteur analyser le modèle littérale, afin que les utilisations suivantes sont tout aussi rapides que les chaînes concaténées; ce qui signifie que la seule différence serait le temps nécessaire pour analyser le modèle littéral une fois.
  • La concaténation de chaîne de cours est plus rapide. Il n'y a pas d'analyse en cours. Il est juste en ajoutant à la longueur de la chaîne. Encore, je voudrais utiliser un modèle de littéraux.
  • Je vais voter pour fermer cette question hors-sujet parce que c'est au sujet de la performance et de l'optimisation
InformationsquelleAutor hurrymaplelad | 2015-03-14
  1. 61

    Il semble pour le moment la concaténation de chaîne est plus rapide: http://jsperf.com/es6-string-literals-vs-string-concatenation

    ES6 with variable                     19,992,512    ±5.21%    78% slower
String concatenation with variable    89,791,408    ±2.15%    fastest
ES6 with function                     461,358       ±3.12%    99% slower
String concatenation with function    503,255       ±1.77%    99% slower

    J'ai testé a été exécuté sur Chrome 43.0.2334.0 canaries (64-bit), qui est à l'aide d'un V8 de 4.3.31, avec la #enable-javascript-harmony indicateur activé.

    Pour référence, la version la plus récente sur Node.js (0.12.0 au moment de l'écriture) est à l'aide d'un V8 de 3.28.73: https://raw.githubusercontent.com/joyent/node/master/ChangeLog

    Je suis sûr que toutes les optimisations de performances qui pourraient être appliquées n'ont pas encore été appliqué, de sorte qu'il serait raisonnable de s'attendre à des performances à obtenir mieux que ES6 se rapproche le plus de la finalisation et de ces caractéristiques transféré à la branche stable.

    Edit: Merci pour les commentaires @user1329482, @icl7126, Nicolai Borisik, et FesterCluck. Maintenant que environ 2 ans ont passé depuis que cette question a été posée, ES6 prise en charge du navigateur a considérablement augmenté, et une bonne quantité de l'optimisation de la performance a eu lieu. Voici quelques mises à jour:

    En Chrome (comme de 59.0.3035), ES6 littéraux de chaîne sont plus rapides:

    ES6 with variable                     48,161,401       ±1.07%    fastest
String concatenation with variable    27,046,298       ±0.48%    44% slower
ES6 with function                     820,441          ±1.10%    98% slower
String concatenation with function    807,088          ±1.08%    98% slower

    Dans Firefox (comme de 57.0.0), ES6 littéraux de chaîne sont plus rapides:

    ES6 with variable                     1,924,610,984    ±0.50%    fastest
String concatenation with variable    1,876,993,458    ±0.79%    3% slower
ES6 with function                     539,762          ±5.04%    100% slower
String concatenation with function    546,030          ±5.88%    100% slower

    Dans Safari (comme de 11.0.2), cela dépend:

    ES6 with variable                     1,382,752,744    ±0.71%    fastest
String concatenation with variable    1,355,512,037    ±0.70%    2% slower
ES6 with function                     876,516          ±1.01%    100% slower
String concatenation with function    883,370          ±0.79%    100% slower

    Lors de l'utilisation d'un transtypage de chaîne, ES6 littéraux de chaîne sont plus rapides. Cependant, lors de l'appel d'une fonction à partir de la traduction littérale, de concaténation de chaîne est plus rapide dans cet exemple.

    Si vous voulez vraiment aller en profondeur et de la nécessité de serrer chaque goutte de performances de Safari, je suggère la configuration de tests voir si/comment mal tapé les variables et les références multiples à l'intérieur d'un littéral de l'effet de la performance.

    • Firefox 50 64 bits - ES6 a la même vitesse que la concaténation 1,423,816,207 Ops/s.
    • Safari 9.0 ES6 des interpolations plus vite que la concaténation de près de 34% de Chrome 55 encore ES6 interpolations beaucoup plus lent que Firefox 50 la même vitesse
    • Modèle de chaînes sont maintenant un ordre de grandeur plus rapide que la concaténation de chaîne. Voir la version 14 de la jsperf, il est le plus précis & impartiale on peut techniquement obtenir, tout en conservant la fonctionnalité aspects. La Version 17 est moins biaisée, mais irréaliste.
    InformationsquelleAutor Andrew Odri
  2. 6

    J'ai fait un naïf test sur node.js v6.0.0 et a obtenu près les mêmes performances. Puisque le test est tellement naïf, ne croyez pas les numéros de trop. Mais il semble que le compilateur JIT génère très optimisé le code de nos jours. Cela m'a permis de décider à préférer les modèles de plus de concaténation pour mon nœud applications.

    Pour la référence c'est le code que j'ai utilisé:

    'use strict'

function strConcat(i) {
    return 'abc' + i + 'def'
}

function strTemplate(i) {
    return `abc${i}def`
}

function run(strategy) {
    let before = new Date().getTime()
    let len = 0
    for ( let i = 0; i < 10000000; i+=1 ) {
        len += strategy(i).length
    }
    console.log(len + ' - ' + ((new Date().getTime()) - before) + 'ms')
}

console.log('strConcat')
run(strConcat)

console.log('strTemplate')
run(strTemplate)

    Et le résultat a été:

    strConcat
128888890 - 1904ms
strTemplate
128888890 - 1979ms

    J'ai utilisé len absolument assurez-vous que l'optimiseur de ne pas optimiser l'ensemble de la boucle de loin. De toute façon, c'est toujours une épreuve très simple. Peut-être que quelqu'un peut faire un plus sophistiquée.

    • J'ai couru un analogue de référence et a obtenu un résultat similaire. Ma référence en matière inclus plus de chaînes, dont certaines sont plus. L'Interpolation des performances légèrement meilleures que la concaténation.
    InformationsquelleAutor analog-nico
  3. 1

    Pour un simple test avec des nombres aléatoires comme une chaîne de caractères, les deux sont à venir si près en Chrome & FF

    Tests en Chrome 58.0.3029 /Windows 10

    Littéraux de chaîne 2,996,883 ±2.36% plus rapide

    De l'opérateur (+) 3,054,078 ±2.01% plus rapide

    Fonction Concat 2,659,391 ±2.35% 13% plus lent

    Tests dans Firefox 53.0.2 /Windows 10

    Littéraux de chaîne 1,923,835 ±1.52% plus rapide

    De l'opérateur (+) 1,948,503 ±1.13% plus rapide

    Fonction Concat 1,810,857 ±1.81% 8% plus lent

    Test d'ici à jsperf

    InformationsquelleAutor Dinesh Rajan
  4. 1

    TL;DR

    Concaténation est plus rapide et plus cohérente par rapport à sa vitesse.
    Mais la différence est très peu pour 1 ou 2 variables (en dessous de 3 secondes pour 100 millions d'appels).

    Modifier

    Après la deuxième manche, il semble que la concaténation est la plupart du temps le plus rapide des deux.

    Donc, je voulais étendre analogique-nico répondre en fournissant un test qui était plus vaste et également cherché (un peu) dans l'évolutivité des deux fonctions.

    Code sur pastebin

    J'ai décidé d'utiliser quatre cas de test pour chaque fonction, d'avoir une variable à l'avant, une à la fin, l'un au milieu et les deux variables dans le milieu. La configuration de base est la même. Je suis juste à l'aide de 100 000 000 d'itérations de la fonction et de ces itérations sont 100 fois.
    J'ai utilisé les mêmes mécanismes pour prévenir l'optimisation, à savoir l'obtention de la somme des longueurs de la résultante des chaînes et de leur enregistrement. J'ai aussi enregistré le temps nécessaire (pour moi de deviner combien de temps ça va prendre), mais aussi enregistrées dans un tableau.

    Par la suite, j'ai calculé la moyenne, minimum, maximum et écart-type pour chaque méthode.

    Voici les résultats:

    { 
sum: { 
t: { 
start: 2072751, 
mid: 2338476, 
end: 2083695, 
double: 2950287 
},
c: { 
start: 2086059, 
mid: 2345551, 
end: 2074732, 
double: 2922929 
} 
},
avg: { 
t: { 
start: 20727.51,
mid: 23384.76,
end: 20836.95,
double: 29502.87 
},
c: { 
start: 20860.59,
mid: 23455.51,
end: 20747.32,
double: 29229.29 
} 
},
sd: {
t: {
start: 335.6251329981114,
mid: 282.9490809315344,
end: 286.2220947096852,
double: 216.40844045461824 
},
c: {
start: 255.4803356424913,
mid: 221.48744862858484,
end: 238.98242111084238,
double: 209.9309074433776 
} 
},
min: { 
t: { 
start: 20490, 
mid: 23216, 
end: 20588, 
double: 29271 
},
c: { 
start: 20660, 
mid: 23258, 
end: 20534, 
double: 28985 
} 
},
max: { 
t: { 
start: 23279, 
mid: 25616, 
end: 22887, 
double: 30843 
},
c: { 
start: 22603, 
mid: 25062, 
end: 22403, 
double: 30536 
} 
} 
}

    valeurs dans t-objets sont pour les modèles, les valeurs c-objets sont pour la concaténation. start signifie que la variable est au début, au milieu qu'il est dans le milieu, la fin que c'est à la fin, et le double il y a deux variables. sum est la somme de tous les 100 exécutions. avg est le moyen terme, c'est à dire sum /100. sd Ici est le chemin le plus facile, wikipedia (anglais). min et max sont le minimum et le maximum de la valeur d'une course, respectivement.

    Résultats

    Il semble que les modèles sont plus rapides pour des variables simples qui ne sont pas situés à la fin d'une chaîne, considérant que la moyenne est plus basse et le minimum est plus faible. Si vous mettez une variable à la fin d'une chaîne ou plusieurs variables dans votre chaîne, la concaténation est plus rapide.

    Bien que le minimum, ainsi que la moyenne des modèles est mieux que de leur enchaînement homologues au sujet de la première des deux conditions, l'écart-type est toujours pire. La différence semble se rétrécir avec plus de variables (plus de tests nécessaires).

    Puisque la plupart des modèles ne sera probablement pas utilisé pour une seule variable dans une chaîne de caractères, il est enregistrez-à-dire que le fait de tenir à la concaténation donne une meilleure performance.
    Mais la différence est (au moins pour l'instant) que très marginalement. À 100 000 000 d' (100 millions) des évaluations à deux variables, la différence est simplement 273,58 ms, environ un quart de seconde...

    Deuxième Manche

    La deuxième manche, l'air un peu différent. Sauf pour la valeur maximale, moyenne, l'écart absolu, et l'écart-type, chaque mesure à l'épreuve la concaténation est plus rapide que les modèles.

    Les trois mentionnés mesures était plus faible (donc mieux) des valeurs pour les modèles lors de la variable a à la fin de la chaîne ou quand il y avait deux variables dans la chaîne.

    Voici les résultats:

    {
"sum": {
"t": {
"start": 1785103,
"mid": 1826679,
"end": 1719594,
"double": 2110823,
"many": 4153368
},
"c": {
"start": 1720260,
"mid": 1799579,
"end": 1716883,
"double": 2097473,
"many": 3836265
}
},
"avg": {
"t": {
"start": 17851.03,
"mid": 18266.79,
"end": 17195.94,
"double": 21108.23,
"many": 41533.68
},
"c": {
"start": 17202.6,
"mid": 17995.79,
"end": 17168.83,
"double": 20974.73,
"many": 38362.65
}
},
"sd": {
"t": {
"start": 858.7857061572462,
"mid": 886.0941856823124,
"end": 786.5366719994689,
"double": 905.5376950188214,
"many": 1744.9005638144542
},
"c": {
"start": 599.0468429096342,
"mid": 719.1084521127534,
"end": 935.9367719563112,
"double": 991.5642274204934,
"many": 1465.1116774840066
}
},
"aad": {
"t": {
"start": 579.1207999999996,
"mid": 576.5628000000003,
"end": 526.8268,
"double": 586.9651999999998,
"many": 1135.9432000000002
},
"c": {
"start": 467.96399999999966,
"mid": 443.09220000000016,
"end": 551.1318000000008,
"double": 610.2321999999999,
"many": 1020.1310000000003
}
},
"min": {
"t": {
"start": 16932,
"mid": 17238,
"end": 16387,
"double": 20016,
"many": 39327
},
"c": {
"start": 16477,
"mid": 17137,
"end": 16226,
"double": 19863,
"many": 36424
}
},
"max": {
"t": {
"start": 23310,
"mid": 24102,
"end": 21258,
"double": 26883,
"many": 49103
},
"c": {
"start": 19328,
"mid": 23203,
"end": 22859,
"double": 26875,
"many": 44352
}
},
"median": {
"t": {
"start": 17571,
"mid": 18062,
"end": 16974,
"double": 20874,
"many": 41171.5
},
"c": {
"start": 16893.5,
"mid": 18213,
"end": 17016.5,
"double": 20771,
"many": 38849
}
}
}

    Le code est ici

    • Je suis en train de tourner une nouvelle version de mon script de test. Il comprend les absolute average mean et la median. Il également des repères de la durée de 10 variables à remplacer.
    InformationsquelleAutor Armin
  5. 0

    Je pense que le test ci-dessus n'est pas utile. Le résultat de l'interpolation ou la concaténation n'est pas utilisé. Donc oui, l'enchaînement est assez rapide, car aucune chaîne d'adaptation, il y et la chaîne de résultat ont des liens de parent des chaînes. Mais si vous allez essayer de la chaîne de résultat ou de comparer avec une autre, la chaîne sera sérialisée avion chaîne et, oui, il va prendre un certain temps. Donc, l'interpolation peut être plus efficace pour le CPU et de la mémoire puis la concaténation dans des cas réels.

    InformationsquelleAutor gev