The only thing which i dont get - why do we have to pass the numbers here?
Due to W3C's TR - they're NOT valid class names.

This handles use cases like this:

classNames('foo', 23); // => 'foo 23'

I know what it does, 23 is invalid classname (as any number leaded string will be), that's I wonder why this lib passes it to result.

I mean I don't know the practical usage of the numbers in classnames, does anyone do like that?

@JedWatson The main idea here is to go away from arrays.
Due to the iterative process we can replace array accumulator with simple string.
It gives us two benefits:

• String concatenation is faster than array push.
• Because we are generating the result on the fly - there is no need of classes.join(' ') which in fact caused second array iteration (first was over the function arguments).

Secondary: i've moved variables declaration out of the loops (it gives pretty big impact).
Plus, IE's optimizer works better if to make typeof separately without storing it's result into a variable.

Bind version works pretty much the same.

Could you quantify the performance differences of everything other than the String concatenation change?
There has been several discussions about the two approaches within this project [and others].

The results appear to vary on every build of V8.

@dcousens it impacts not only the V8 based browsers, FF has performance improvements too.
But as i mentioned above - logically, strings based approach has a benefit of one less array iteration (at the end when joining happens).

In general, i suppose all other changes will give around 2-5% performance improvenet.

@JedWatson almost the same optimisation reason here (but the real showstopper here is strings split, with which we can do nothing).
But here we had even worse situation in terms of iteration:

• Lines 76-80 are literally useless. It creates new, real array of arguments elemnts and then araing iterates over newborn array at lines 87-91; It would've made sence if you passes that array further to other functions but not here.
• And then, again, simply aviding the array accumulator while building the final string;
• Futrthermore i've simply merged parsers into single function, that gives us economy on function calls;

Since we're chasing milliseconds, won't it be faster to just assign once?

str = (str ? ' ' : '') + item;

Practically, for v8 my aproach is faster, for other browsers they're almost equal;
I suppose it is caused by prediction branching.
In your way you have 2 concats all the time, in mine - 1 guaranteed and one optional;

Yes, but my gut feeling was that the extra concat done on item 0 is worth avoiding the extra variable mutations for items 1+.

@krawaller benchmarks result:
mine: local#strings x 14,682,684 ops/sec ±1.21% (89 runs sampled)
yours: local#strings x 14,028,615 ops/sec ±1.01% (89 runs sampled)

It is obviously a very small difference but if it can be done - why not =)

Yeah, I guess we've left the real world far behind. :)

Still, very interesting! I really thought variable mutation would be more expensive, but yours win out. Predictive branching for the win, I guess!

@krawaller tbh first time i've seen the results i've been wondered too =)
First iteration code been written as yours %)