Neither does jQuery interpret a return of undefined as a stopPropagation, as this fiddle shows:
Both versions have the same return value as illustrated by this fiddle http://jsfiddle.net/QHxJ3/
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]
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.
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?
https://github.com/jquery/jquery/blob/a5037cb9e3851b171b49f6...
So returning undefined does NOT stop propagation.
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.
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.
