

JavaScript Performance MythBusters (via jsPerf) - tilt
https://docs.google.com/present/view?id=0Ac0YlG9vMA2LZHE1MnpycF8yMGZ6ZnZxa2hy&pli=1

======
jensnockert
I think you need the talk to be able to understand what they meant.

Because I for one haven't heard any rumors that forEach is faster than a for
loop for example, and a lot of the other stuff.

There is also a lot of things that are true in certain browsers but not
others, if you want the fastest possible performance you probably need to
optimize per engine. (But that is overkill for most Javascript applications)

~~~
jdd
The point of this test is to show that by creating your own custom forEach-
lite or other native-lite implementations you can get better performance over
native.

Many times you don't need to support all of the functionality/edge cases of
the native method and that allows you to gain performance/custom-functionality
and save code because you no longer need to have an ES5 compliant fallback.

Many libs, like Underscore.js, fork for native methods but could reduce
code/gain speed if they settled for simpler methods.

Most devs don't care about supporting sparse arrays or ToUint32'ing a `length`
value and this allows us to optimize for the common case.

Also, by implementing a custom method you can gain functionality like exiting
early by explicitly returning `false` or method chaining.

<http://jsperf.com/for-vs-array-foreach/4>

------
fridek
Some of the tests they link prove the opposite of what they say in the slides.
Also, saying that eval is not evil is evil.

~~~
mikegirouard
My eval tests said the same. I'm not sure if thats indicative of a host-
specific performance problem or if it is with eval itself.

Perhaps the problem I have is with this statement:

> "Eval is evil", or in other words, Eval is too slow and quirky to be
> considered useful.

That's misleading. While performance of eval is perhaps getting better, eval
is still evil for a number of reasons that aren't related to performance at
all.

~~~
fridek
Eval breaks both JIT[1] and garbage collection [2] (unless used very
carefully). It also affects Google Closure Compiler [3]. What is even better -
it won't ever be fixed, at least not in the terms of performance.

[1] <http://echo.nextapp.com/site/node/6097>

[2] [http://stackoverflow.com/questions/5368048/how-are-
closures-...](http://stackoverflow.com/questions/5368048/how-are-closures-and-
scopes-represented-at-run-time-in-javascript)

[3] [http://groups.google.com/group/closure-compiler-
discuss/brow...](http://groups.google.com/group/closure-compiler-
discuss/browse_thread/thread/e01e087142784940/4e4dd45ee97fc1c8)

~~~
jdd
Garbage collection was brought up during the Q/A and I would dig a jsPerf
revision to explore that.

One of the tests included in the slides was to see if simply using `eval` in a
method would disable optimizations: <http://jsperf.com/eval-kills>

Chris (@robodynamo) included the slide about `eval` because he found it
performant/useful in his day job.

Eval has it's uses, for example it's used in json2.js as part of the JSON
fallback.

------
TurplePurtle
Repeating what I said on Reddit: The Regexp vs. indexOf test seems a little
misleading. Generally, .indexOf will be faster, but they seem to have
performed a very specific test that requires the indexOf method to do some
string concatenation before actually searching, which IMO invalidates the
usefulness of the test.

Please correct me if I'm wrong.

The test I'm talking about: <http://jsperf.com/regexp-indexof-perf>

~~~
jdd
The point of this test is to show that you should avoid making blanket
assumptions about performance and that you shouldn't fear the RegExp :)

You can see my full reply here: <http://jsperf.com/regexp-indexof-
perf#comment-3>

~~~
WayneDB
You're still testing concat + indexOf, not just indexOf. I think that test is
broken.

~~~
jdd
The test isn't broken in the scope of its use case. You are totally missing
the point which is RegExp's are no longer a guaranteed fail when it comes to
performance and that in many situations, including that jsPerf test, can out
perform the indexOf equivalent.

~~~
WayneDB
I think that a lot of people would just like to see a direct comparison,
that's all.

------
udp
Any chance of getting these in a plain old list? Kinda painful to read when
it's not a presentation.

------
jdd
The audio from the SXSW panel discussion can be found here:
<http://lanyrd.com/2012/sxsw-interactive/spgqq/>

