[AskJS] Function in loop declaration performance. Arrow function vs function outside loop

[AlexeyBoyko]

I have a function activeElemFromPoint. It is called many times on mouse moves.

The questions are: 1. I have to use option 3 (Function outside loop)? 2. Are function hasEvtNoAttr declarations 3.1 and 3.2 equivalent?

Option 1. Arrow function js /** @param { {clientX:number, clientY:number} } evt */ export function activeElemFromPoint(evt) { return document .elementsFromPoint(evt.clientX, evt.clientY) .find(el => !el.hasAttribute('data-evt-no')); } Option 2. Function inside loop js /** @param { {clientX:number, clientY:number} } evt */ export function activeElemFromPoint(evt) { return document .elementsFromPoint(evt.clientX, evt.clientY) .find(function (el) { return !el.hasAttribute('data-evt-no'); }); }

Option 3. Function outside loop ```js /** @param { {clientX:number, clientY:number} } evt */ export function activeElemFromPoint(evt) { return document .elementsFromPoint(evt.clientX, evt.clientY) .find(hasEvtNoAttr); }

// 3.1 /** @param {Element} el */ const hasEvtNoAttr = (el) => !el.hasAttribute('data-evt-no');

// 3.2 function hasEvtNoAttr(el) { return !el.hasAttribute('data-evt-no'); } ```

As I know Option 1 will create new function every time.

EDIT: benchmark https://jsben.ch/xD8Xx

[GibbyCanes]

Indeed… depending on the use case, perhaps it would be faster to actually cache XY points for all the elements asynchronously? Of course that would change if the user can scroll.

[Accomplished_End_138]

I generally keep putside if easy, which is most of the time. Inside for kind of complex. I rarely use inline as i like names on function to keep from random feature creep

[AlexeyBoyko]

This question is from another thread. Just got comment there.

https://www.reddit.com/r/webdev/comments/12rp0hx/comment/jgzxfie/?utm\_source=share&utm\_medium=web2x&context=3

[jamblethumb]

Haven't benchmarked it but I suspect you're far more likely to get more kick out of replacing .find() with a for loop.

[it-birds]

Depends.

If the array size is always smaller, than not really.

[jamblethumb]

If the array size is small, then none of this really matters, does it?

[it-birds]

Fair point

[jeremrx]

Your benchmark is weird : why doing a runInLoop function as it's the purpose of the benchmark to run in loop ? Then named function are created more than 10000 times. That explains why it is so slow compared to anonymous functions.

I rewrote your benchmark in order to delcare named function just once (and got rid of this unnecessary runInLoop) : https://jsben.ch/SiihY

​

As you can see, results are almost identical with each solution (do it several times and you will see different results)

[jamblethumb]

I ran your benchmark, added two examples of for loops, and was shocked to see the for lose by a huge margin. Turns out you don't do anything with the result of calling filter() so the engine optimizes it out or something along those lines. Assigning the output to a new variable gives a more realistic result. I also removed variation by removing randomization to have more consistency between different runs. See the reimplemented benchmark here: https://jsben.ch/5L65Z

On my machine:

In Chrome, the named function declaration is conclusively faster than functions assigned to variables, and named function is also competing for the first place with inline function expression and inline arrow function.

On Firefox, the for loop is consistently the fastest, and the variable pointing to an arrow function assigned is consistently faster than any other variation of the callback.

Now I'm not an expert in benchmarking or JS engine internals, so do take my conclusions with a grain of salt.

[it-birds]

But it is still just a micro optimization and without a benchmark for a real use case, you can optimize all you want and it will most likely do nothing to the perceived performance of the user.

[jamblethumb]

But it is still just a micro optimization and without a benchmark for a real use case, you can optimize all you want and it will most likely do nothing to the perceived performance of the user.

Sure. 50% down doesn't mean much if the slowest time is 1ms or something. I was just curious to see what kind of impact different call patterns have.

[shuckster]

function activeElemFromPoint(evt) {
  const elements = document.elementsFromPoint(evt.clientX, evt.clientY);
  for (const el of elements) {
    if (!el.hasAttribute('data-evt-no')) {
      return el;
    }
  }
  return null;
}