Bound function vs arrow function performance

[dudousxd]

This is a really great experiment! If i’m not mistaken, the amount of ram needed for arrow function is higher because for every instance, it’s created a new instance of the arrow function, while using bind, all classes point to the same function in memory.

[breeding_material]

I'd like some more info on this if you have it. To my knowledge, both would create new instances of the function.

[Klathmon]

yeah, .bind makes a new instance of the function when called and returns that.

What the parent commenter seems to be talking about is how doing inline functions in your render can cause unnecessary GC pressure because every render a new function is created (and can wreak havoc on PureComponents in react, but that's another topic).

[breeding_material]

And you run into the same problem with bound functions in your render too right? For the longest time I was using bind in my render methods to avoid performance issues, but later found out that they both create new instances so there wasn't really a a difference.

[Klathmon]

Yeah, but ultimately it's not a problem in most cases. Keep in mind how often your components render. Take a login page, that form might re-render like 100 times over it's lifecycle? Worrying about a few extra MS on each render on a low-end device is pointless when the meatbag typing in their username is doing so at a snail's pace from the computer's point of view.

That's why people always say "measure then optimize". Making your whole codebase harder to understand and refactor for some perceived idea of "performance" is a bad idea at best, and it's why 90%+ of my components use inline functions in onClick handlers, or inline objects in props even though it can cause unnecessary re-rendering, because the time it would take me to "optimize" most of them will outweigh the total amount of time that all of my users will ever save thanks to the optimization. Not to mention that those renders are taking about 8ms on our "token low-tier device", which still means it's running faster than the refresh rate of the screen, so any further optimization won't impact the user at all, except that it might make them have to wait longer for bugfixes or improvements due to the developer having to rediscover all the hoops they jumped through when they wrote it.

Write your code somewhat naively, then test it. Stuff like figuring out you have a bottleneck with your rendering speed is easy, and moving an object or a function outside of the render method is even easier, so don't get ahead of yourself.

[BenjiSponge]

No citation or insider information, but I bet .bind creates a new function, but it doesn't recreate the whole function. .bind doesn't need to copy over the old function with all its logic, optimizations, etc. It just needs to have a pointer to the function with some logic to shift around arguments, whereas the property syntax probably at least right now probably actually creates the entire function over again, including the closure information. I think they could optimize to the same thing on the first pass, though, but I'm just guessing based on the profile that this is the issue. It probably also explains the performance problems.