

Always return on events is faster, but why? - angelomichel_nl
http://jsperf.com/always-return-on-jquery-events

======
mraleph
Answer is simple: you are adding more and more listeners as jsPerf runs your
test case.

One of the most important things to remember while using jsPerf is that setup
phase can and will be executed multiple times. As the result the list of
listeners attached to the DOM node is growing and this in turn slows down the
event dispatch.

"No return" case is run second so the list of listeners is already large and
thus it is slower than "return case".

You should either unregister listeners in tear down phase or register them
only once at global initialization time. Here is the fixed variant:

[http://jsperf.com/always-return-on-jquery-
events/28](http://jsperf.com/always-return-on-jquery-events/28)

[also from the JavaScript VM point of view function () { } and function () {
return; } are completely the same]

~~~
esailija
Also another mistake here is the classical "if you want to measure x, don't
measure y".

If the OP wanted to measure function with or without return , even without
realizing how futile that is, they still should not include things like
jQuery.

~~~
sesqu
Well, before the GP post, my takeaway was that it's better to return _when
using jQuery_. The justification for this would have been some magic, which is
the sole purpose of jQuery, slowing stuff down.

And the web being as it is, testing with jQuery might even be more useful than
testing without it.

~~~
esailija
That is a common fallacy and benchmarking anti-pattern, and it really enrages
me that some people look at the completely incorrect results and justify it
with "I am going to be using this with jQuery so why shouldn't I add some
jQuery method calls". And you are denying this despite the "fixed" js perf
showing different results e.g. on chrome 29.

You should read
[http://zedshaw.com/essays/programmer_stats.html](http://zedshaw.com/essays/programmer_stats.html)

~~~
sesqu
I think you misunderstood. I'm denying nothing.

What I meant was that if I'm going to run a website with jQuery calls, I
should absolutely test with jQuery calls. It makes no sense to claim that one
should, say, always use short variable names, if one then ships with google
closure.

------
smilekzs
Revision 3 revealed that it's not the `return` that made the difference --
it's the jsperf runner failing to introduce sufficient time gap between
testsuites for it to "settle down"...

~~~
Sidnicious
eulerphi: FYI you're hellbanned

~~~
Cthulhu_
Isn't the idea of hellbanning that people don't realize they are? Kinda
defeats the purpose if you notify them of it. If HN wanted people to know
they've been silenced, they would be given an error message. So, don't tell
people. It's also spamming the comment with offtopic remarks.

~~~
Dylan16807
Using hellbans when you should be using normal bans or even temporary bans is
a horrible system.

Most people that are hellbanned on HN have not at all deserved it. Ignoring
spambots, I've seen perhaps two users that got a hellban for consistently
problematic posts rather than a single post annoying someone. And one of those
has actual mental issues.

~~~
bicknergseng
His interaction with the hn community (and vice versa) is actually one of the
most interesting things I've seen on hn.

------
andremedeiros
If you use the browser's "onclick" or "onmouseout" properties instead of the
jQuery event calls, the result is very similar:

[http://jsperf.com/always-return-on-jquery-events/5](http://jsperf.com/always-
return-on-jquery-events/5)

------
angelomichel_nl
Allright.. So most likely, return or no return does not make any difference.
Or at least that is the feeling I get from Colin's revision (3). Myth busted?
Or is there another tail to the story.

------
callum85
Both functions return "undefined". They should be identical after JIT
compilation.

The only thing I can imagine taking longer would be the compilation step
itself... but I had always assumed jsPerf didn't work like this, i.e. I
thought it would wrap the test code in a 'for' loop and then eval the whole
loop, rather than doing the eval call inside the loop.

------
Tichy
Maybe because "some_el_2" is lower down in the DOM tree? I think at least the
experiment should be run with reversed IDs.

~~~
recentdarkness
It shouldn't matter because if you swap the execution order, the 'no return'
can be faster too in that test.

------
kiplinger
Is there some low level checking by the js engine to see if it should stop
processing the function if there is no return? Or, to put it another way, does
adding the return explicitly tell the engine, "ok we're done here", as opposed
to a small amount of processing required by the engine to determine that for
itself?

------
rrzar
In fact it's not really faster, if you run the test several times the results
are similar.

It's the same thing if you compare the selectors $(this) and $((((this))));

I don't know why, but the problem must come from jsperf. Thats why when I use
this tool I always run it at least 5 times to be sure.

------
dominicglenn
I posted it on the page as well:

Doesn't just calling return from an event equate to returning boolean false,
which means you are invoking the effects of preventDefault() and
stopImmediatePropagation() thus explaining why with return it's faster as the
event stops bubbling immediately?

~~~
EmielMols
No. It equates to returning undefined, which is the same as having no return
statement at all.

~~~
dreen
Although it obviously isn't quite the same. I wonder what is the test result
for no return vs return true

~~~
Tarang
Still faster, check revision 6 [http://jsperf.com/always-return-on-jquery-
events/6](http://jsperf.com/always-return-on-jquery-events/6)

revision 7 [http://jsperf.com/always-return-on-jquery-
events/7](http://jsperf.com/always-return-on-jquery-events/7). Just return vs
return true (faster).

But as smilekzs points out revision 3 this might not be about the return
statement.

------
lukashed
Doesn't a return without argument return false and thus have the same effect
as preventDefault()? That would explain the difference, since the events are
not "bubbling up".

~~~
Tarang
return without return false is just like breaking out of a method i think..
The events would still bubble since false isn't returned

~~~
K0nserv
An empty return statement has the return value undefined which is falsy. As
lukashed said jQuery most likely interprets this as false and stop propagation
of the event, however using an empty function also has the return value
undefined so both cases stops propagation.

Both versions have the same return value as illustrated by this fiddle
[http://jsfiddle.net/QHxJ3/](http://jsfiddle.net/QHxJ3/)

~~~
Tarang
Interesting, I would have never thought the js interpreter would interpret
both as being === even though the two functions are different.

~~~
Stratoscope
The two _functions_ are different, but their _return values_ are identical.
The === is comparing the return values.

Consider this example:

    
    
      function onePlusOne() { return 1 + 1; }
      function two() { return 2; }
    
      alert( onePlusOne === two );  // false, not the same function
      alert( onePlusOne() === two() );  // true, same value

------
hqm42
Revision 22 revealed that something went terribly wrong...

------
elwell
the first time i ran the tests "no return" was faster

