Shorthand for "function" keyword

Isiah Meadows isiahmeadows at gmail.com
Sun Nov 12 15:53:39 UTC 2017


That sounds like a major V8 bug that [should be reported][1] - there
should be zero performance difference between an arrow function and a
normal ES5 function. They're completely equivalent apart from ES5
functions being constructible and arrow functions forming a closure
around the current call context. In particular, I'd expect them to be
*faster*, not slower.

[1]: https://bugs.chromium.org/p/v8/issues/list
-----

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Sun, Nov 12, 2017 at 5:45 AM, J Decker <d3ck0r at gmail.com> wrote:
>
>
> On Sun, Nov 12, 2017 at 2:14 AM, T.J. Crowder
> <tj.crowder at farsightsoftware.com> wrote:
>>
>> On Sun, Nov 12, 2017 at 9:56 AM, J Decker <d3ck0r at gmail.com> wrote:
>> > Arrow functions passed as callback to Node.js addons execute 20%
>> > slower than regular 'function()' functions.
>>
>> **Wow**. Is that written up somewhere one could read more?
>>
>> When you say "Node.js addon," are you excluding built-in Node APIs?
>
>
> Basically it was an empty function I was calling with some simple parameters
> It was only something I found through experimentation.  It really has
> nothing to do with NodeJS other than it was an addon, it was just
> interacting with the V8 engine.
>
> Writing file...
> Wrote in  199  .. reading...
> ()=>{} Read in ... 300000 3394
> function(){} Read in ... 300000 2690
>
> https://github.com/d3x0r/sack.vfs/blob/master/tests/largeStreamtest.js#L15
> and line 18 is the other one.
> In the function I just increment a counter....  126% or 79.25%  ...but then
> there is quite a bit of overhead in my library to parse the JSON. that's
> quite a nested object
> `{\"a${i}\":{\"b${i}\":{\"c${i}\":{\"d${i}\":123}}}}`
> --------------
> Hmm... changed the file that was being generated to just a simple string,
> and the timings were closer (but was less than 1 second run) so I added some
> generation counts and ran the tests in various orders... and I guess maybe
> it was because of other factors that coincidentally showed as ()=>{} being
> slower than function(){}
>
> function(){} Read in ... 100000 958
> ()=>{} Read in ... 100000 906
> ()=>{} Read in ... 100000 784
> function(){} Read in ... 100000 783
> ()=>{} Read in ... 100000 924
> function(){} Read in ... 100000 779
> function(){} Read in ... 100000 881
> ()=>{} Read in ... 100000 805
>
> then just reversed the two tests in the original script and the timing
> stayed the same in-order... but then would show function() as being the
> slower one.
>
> My Bad; thanx for asking about that though I would have been stuck with that
> misconception for a long time.
>
>
>>
>> -- T.J. Crowder
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list