Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Always return on events is faster, but why?

jsperf.com

Post reply on HN
Print view View original

11–20 of 52 posts

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

#11

Post by Tarang »

dreen wrote: post #7
EmielMols wrote: post #3

Earlier quoted context omitted.

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.

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

#12

Post by [deleted] »

Tarang wrote: post #6
lukashed wrote: post #4

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 return false is just like breaking out of a method i think.. The events would still bubble since false isn't returned

[deleted]

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

#13

Post by K0nserv »

Tarang wrote: post #6
lukashed wrote: post #4

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

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

#15

Post by bengillies »

lucideer wrote: post #9
EmielMols wrote: post #3

Earlier quoted context omitted.

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

!!undefined === false

right. undefined is falsy, but it's quite different to false (i.e. undefined !== false)

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

#18

Post by 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.

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

#19

Post by eulerphi »

smilekzs wrote: post #14

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

It's not the jsperf runner, ie. any "settling" of GC sweeping, or anything of that nature.

It's surprisingly the location of the DOM elements. See here, I've swapped the two elements, and now the result is _backwards_

http://jsperf.com/always-return-on-jquery-events/21

Can anyone with knowledge of the webkit internal DOM id-based key/hashtable shed light on this?

I'm guessing that for the 2nd child, when it's propagating upwards, it has to hit 1 more element -- that is, if it must reach the first child to get the parent. I'd hope that the structure is more optimized than a simple crawl to the first node to go upwards.

EDIT: Actually, I'm wrong. I edited the test to have 6 divs, and re-arranged the order of the tests. The tests still come in performance-wise from first-to-last, first performing the best. I really don't know what to think now.

Post reply on HN