This is used many times in the hot path. The main motivation for
this is to reduce memory churn in that path.
By building up a string directly instead of first mapping into an
array, and than using Array#join() - we avoid some of that churn.
It terms of speed, avoiding Array#join resulted in the same
or better performance for the browsers I tested.
| | Chrome 60 | Safari 11.1 | Firefox 61
| map+join | 241K/s (± 2%) | 189K/s (± 5%) | 161K/s (± 6%)
| forEach+concat | 297K/s (± 1%) | 398K/s (± 2%) | 159K/s (± 13%)
| reduce | 437K/s (± 2%) | 396K/s (± 1%) | 138K/s (± 12%)
For Chrome and Safari, 'reduce' were marked "fastest".
For Firefox, JSPerf marked all three as fastest due to the
variable ranges overlapping. Re-runs produced similar results,
each time with three cases laid out in a slightly different order
in the 130-165K/s range. The test used a copy of en.wikipedia's
current registry with the module queue of a random article.
https://jsperf.com/array-map-and-join-vs-string-concat/1
Change-Id: Ifbd8f6509ac118657c5ad2833f54fd6e8e63f9ce
* @return {string} Hash of concatenated version hashes.
*/
function getCombinedVersion( modules ) {
* @return {string} Hash of concatenated version hashes.
*/
function getCombinedVersion( modules ) {
- var hashes = modules.map( function ( module ) {
- return registry[ module ].version;
- } );
- return fnv132( hashes.join( '' ) );
+ var hashes = modules.reduce( function ( result, module ) {
+ return result + registry[ module ].version;
+ }, '' );
+ return fnv132( hashes );