Live data from Hacker News

Always return on events is faster, but why?

jsperf.com

41–50 of 52 posts

Re: Always return on events is faster, but why?

#41
post #35

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…

Well at least now I know how to manipulate JSPerf results in a non-obvious way :X

Re: Always return on events is faster, but why?

#42
post #39
post #13

Earlier 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.

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

Re: Always return on events is faster, but why?

#43
post #13
post #6

Earlier 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/

> 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:

  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?

#44
post #35

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…

I love that you proved this wrong so quickly. Saved me from going and adding returns across a bunch of projects. Thanks!

Re: Always return on events is faster, but why?

#45
post #35

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…

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.

Re: Always return on events is faster, but why?

#46

Earlier 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.

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.

Re: Always return on events is faster, but why?

#47

Earlier 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.

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

Re: Always return on events is faster, but why?

#49

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... ?

Re: Always return on events is faster, but why?

#50
post #45

Earlier 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.

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

Post reply on HN