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…
Always return on events is faster, but why?
41–50 of 52 posts
Re: Always return on events is faster, but why?
#42Earlier quoted context omitted.
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/
Interesting, I would have never thought the js interpreter would interpret both as being === even though the two functions are different.
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 valueRe: Always return on events is faster, but why?
#43Earlier quoted context omitted.
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/
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();
}
}
https://github.com/jquery/jquery/blob/master/src/event.js#L3...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();
}
}
This would also have the same effect: if ( ret !== undefined ) {
event.result = ret;
}
if ( ret === false ) {
event.preventDefault();
event.stopPropagation();
}
These all do the same thing: set event.result only if ret is not undefined, and then call preventDefault and stopPropagation only if ret is false (and not just a falsy value).Re: Always return on events is faster, but why?
#44Answer 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…
Re: Always return on events is faster, but why?
#45Answer 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…
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.
And the web being as it is, testing with jQuery might even be more useful than testing without it.
Re: Always return on events is faster, but why?
#46Earlier quoted context omitted.
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.
I posted the jQuery code in a previous comment; take a look at that and you can see how it works.
Re: Always return on events is faster, but why?
#47Earlier quoted context omitted.
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.
Re: Always return on events is faster, but why?
#48Re: Always return on events is faster, but why?
#49Revision 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
Re: Always return on events is faster, but why?
#50Earlier quoted context omitted.
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.
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.
You should read http://zedshaw.com/essays/programmer_stats.html