Always return on events is faster, but why?(jsperf.com)
jsperf.com
Always return on events is faster, but why?
http://jsperf.com/always-return-on-jquery-events
12 comments
I love that you proved this wrong so quickly. Saved me from going and adding returns across a bunch of projects. Thanks!
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.
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.
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.
And the web being as it is, testing with jQuery might even be more useful than testing without it.
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
You should read http://zedshaw.com/essays/programmer_stats.html
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.
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.
Well at least now I know how to manipulate JSPerf results in a non-obvious way :X
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"...
eulerphi: FYI you're hellbanned
Uh... What happened? Just realized my comment wasn't 100% accurate (it's multiple event listeners rather than unsettled event) but... ?
Sorry for the hijacking.
Someone named eulerphi replied to your comment, but they're "hellbanned" from Hacker News and their reply is only visible if you turn on showdead in your settings.
Someone named eulerphi replied to your comment, but they're "hellbanned" from Hacker News and their reply is only visible if you turn on showdead in your settings.
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.
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.
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.
His interaction with the hn community (and vice versa) is actually one of the most interesting things I've seen on hn.
I browse with showdead on because frankly, apart from the occasional commentspam, pretty much none of the comments I see from hellbanned users are from users who persistently make comments that would seem to justify a ban of any kind. Most of them appear to just have made a single stupid comment at some point or other that perhaps deserved some downvoting. It seems to me that hellbans are overused.
And the answer to it being overused is for people to call it out whenever a user is trying to contribute but hellbanned, and we don't agree with the ban after taking a look at their comment history.
And the answer to it being overused is for people to call it out whenever a user is trying to contribute but hellbanned, and we don't agree with the ban after taking a look at their comment history.
Sure, that's the idea. The comment looks totally legit and relevant, though.
Looks like their last comment sucked, and it's easier for a mod to ban someone than to reply, “that comment sucked” and hope they get better. Mods are never perfect, they have a big job, and people can (successfully) appeal hellbans.
Looks like their last comment sucked, and it's easier for a mod to ban someone than to reply, “that comment sucked” and hope they get better. Mods are never perfect, they have a big job, and people can (successfully) appeal hellbans.
Not sure what previous action caused him to get hell banned but his comment was trying to contribute something to this thread. Think it would be nice to know if I was banned and still trying to contribute.
Can't really recall a single hell ban I agree with. So the fact that everyone tries to warn the posters who have been banned kind of shows it is being misused. I would prefer it only be used on spammers and intention trolls/personal attacks. On HN it gets used far more, however. So I agree with everyone who warns people, basically.
Maybe, but it's pretty obvious when it happens. And of course if that weren't enough, every time you post people tell you that you're hellbanned.
[deleted]
[deleted]
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
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.
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.
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.
Maybe because "some_el_2" is lower down in the DOM tree? I think at least the experiment should be run with reversed IDs.
It shouldn't matter because if you swap the execution order, the 'no return' can be faster too in that test.
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?
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.
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.
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?
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?
FWIW, the underlying jQuery code explicitly tests for false with ===:
https://github.com/jquery/jquery/blob/a5037cb9e3851b171b49f6...
So returning undefined does NOT stop propagation.
https://github.com/jquery/jquery/blob/a5037cb9e3851b171b49f6...
So returning undefined does NOT stop propagation.
No. It equates to returning undefined, which is the same as having no return statement at all.
Although it obviously isn't quite the same. I wonder what is the test result for no return vs return true
Still faster, check revision 6 http://jsperf.com/always-return-on-jquery-events/6
revision 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.
revision 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.
!!undefined === false
right. undefined is falsy, but it's quite different to false (i.e. undefined !== false)
true, but a boolean return value is expected for event listener callbacks.
That's not quite how it works. jQuery checks specifically for false with an === comparison. It doesn't do anything like a !! on the return value to convert it to boolean true or false. It only calls stopPropagation and preventDefault when the return value is false, not just any falsy value.
I posted the jQuery code in a previous comment; take a look at that and you can see how it works.
I posted the jQuery code in a previous comment; take a look at that and you can see how it works.
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".
Return without a value returns undefined, which is falsy but not false.
As many pointed out, I was wrong. An empty return doesn't equal a false return.
Neither does jQuery interpret a return of undefined as a stopPropagation, as this fiddle shows:
http://jsfiddle.net/6UGN8/
Neither does jQuery interpret a return of undefined as a stopPropagation, as this fiddle shows:
http://jsfiddle.net/6UGN8/
Have you been explicitly returning true all this time?
I think `function(){}` and `function(){return;}` are equivalent, at least functionally... Still can't explain the time difference, though.
return without return false is just like breaking out of a method i think.. The events would still bubble since false isn't returned
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/
Both versions have the same return value as illustrated by this fiddle http://jsfiddle.net/QHxJ3/
> As lukashed said jQuery most likely interprets [undefined] as false and stop propagation of the event...
No, it doesn't. jQuery uses a strict test for false and does not stop propagation for other falsy return values from an event listener.
The documentation could be more clear on this point. All it says is: "Returning false from an event handler will automatically call event.stopPropagation() and event.preventDefault()."
http://api.jquery.com/on/#event-handler
Here's the code that does this check:
Reading that code, it almost seems redundant at first to have a !== undefined check when the === false is already a strict comparison. But there is that assignment hidden inside the if expression. So the code is really the same as this more clearly written version:
No, it doesn't. jQuery uses a strict test for false and does not stop propagation for other falsy return values from an event listener.
The documentation could be more clear on this point. All it says is: "Returning false from an event handler will automatically call event.stopPropagation() and event.preventDefault()."
http://api.jquery.com/on/#event-handler
Here's the code that does this check:
if ( ret !== undefined ) {
if ( (event.result = ret) === false ) {
event.preventDefault();
event.stopPropagation();
}
}
Reading that code, it almost seems redundant at first to have a !== undefined check when the === false is already a strict comparison. But there is that assignment hidden inside the if expression. So the code is really the same as this more clearly written version:
if ( ret !== undefined ) {
event.result = ret;
if ( ret === false ) {
event.preventDefault();
event.stopPropagation();
}
}
if ( ret !== undefined ) {
event.result = ret;
}
if ( ret === false ) {
event.preventDefault();
event.stopPropagation();
}
Interesting, I would have never thought the js interpreter would interpret both as being === even though the two functions are different.
The two functions are different, but their return values are identical. The === is comparing the return values.
Consider this example:
Consider this example:
function onePlusOne() { return 1 + 1; }
function two() { return 2; }
alert( two ); // false, not the same function
alert( onePlusOne() === two() ); // true, same value[deleted]
Revision 22 revealed that something went terribly wrong...
the first time i ran the tests "no return" was faster
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
[also from the JavaScript VM point of view function () { } and function () { return; } are completely the same]