[].join isn't that slow

[GreLI]

You wrote

Judgement call, the slowest known method is [].join. If you are building something that requires high performance do not use [].join. It's not bad, it's just not performant. The two fastest methods of multiline are one-line strings (no breaks), and in second using the \ character (breaks), with + (concat) trailing slightly behind. I'll let hard data back me up on this.

The test you refer to isn't quite correct. Modern JS engines do optimize and precompile code, so, when JSPerf run it multiple times, it just get the strings as fast as it gets a simple variable, but it doesn't so with the [].join().

It takes time for engine to preoptimize a code, but for the string (any option) it counts only once, while the join operation counts every executing time. Since you are running an actual code only once, it's incorrect to refer to this test.

[nijikokun]

Should you build it in a way that, lets say inside a while or for loop inside of a function then it will do O(n) in comparison to a strings O(1). Every. Single. Time. Especially if you are dealing with dynamics. Regardless of the eventually performant JIT, and even on the JIT "Optimized" compiler it will still be slower than a string.

This is not optimized and not performant, and when you are creating something like a game engine, or something that deals with high throughput, you wouldn't want to use [].join in these scenarios, it actually does affect performance.

The test I refer to, is rendered on not only V8, one of the leading Engines, using their JIT concurrent compiler, but other engines showing the performance of one way to another at high throughput, and this in my mind is where you want performance.

Should you want further performance tips, here is a huge list from 2011, and there are more since then.

Once again, this is a judgement call, as not everyone is developing game engines or code that needs high throughput, so if you are making code that gets executed once or every 20 seconds or more, it should be fine.

That said, my favourite way to deal with variables and strings, is [].join, when I know it's not going to affect anything performance wise.

[GreLI]

I doubt that anyone places [].join() in a loop. As far as I remember, join() is the most perfomant in slow old browsers like IE – the only place where it really can be important. In other cases it doesn't really matter. Also, it's hard to find a testcase which is optimization-aware, so it wouldn't be affected by browser preoptimization so that results are truthworthy.

[nijikokun]

I'm sure someone has, templating would be an area that I could see it happen (especially cases where someone rolls their own and is new or unaware of performant code).

I'm going to close this, as in my eyes, it's a reliable test given the most common place where code will be put (the browser) the only place where I can agree that this can change is server based code or separately compiled code, given those environments, I'm sure that you are aware of what you are doing performance wise. Hence judgement calls.

Also, as a note for IE7 and below, because IE used a concatenation handler that would repeatedly copy strings, causing an exponential increase in memory usage and time. Which could cause at high performance the browser to lock during the throughput, and take to an upwards of 150,000ms to compute, where [].join could take somewhere around 100 ~ 200 ms.

[nijikokun]

I've updated the paragraph with some additional information that I felt was useful to know.