5 ms·

This is cool, but array methods are so rarely the bottleneck; Even in the highly-specialized demo, the difference is near-negligible. It's a fun project and mi

This is cool, but array methods are so rarely the bottleneck; Even in the highly-specialized demo, the difference is near-negligible. It's a fun project and might have application in specialized situations (and maybe for Node, where time spent in synchronous iteration blocks all other requests?). But I feel like this does more harm than good in most cases (larger bundle, extra build step, less readable output code can make debugging harder, etc)

vzhou842 9y ago
Agreed for the most part - this realistically does not have a good generalized use case. IMO the only real harm is the slightly larger bundle, though - I think the extra build time is negligible and you could just disable this optimization when developing. My main motivation for building this was to make a better way to use an optimization library like fast.js (https://github.com/codemix/fast.js https://github.com/codemix/fast.js), which inspired faster.js. A huge issue with the fast.js library is that you have to rewrite your entire codebase in order to use it, whereas enabling or disabling faster.js is a one line change.
rococode 9y ago
I agree, while this is a cool idea it doesn't seem to be useful beyond being a proof of concept of an optimization technique. For example, my browser rendered the faster.js version 50ms slower at this point: https://i.imgur.com/G5b10Ns.jpg https://i.imgur.com/G5b10Ns.jpg. It does appear to perform better in the long run (https://i.imgur.com/u3ApYYl.jpg https://i.imgur.com/u3ApYYl.jpg) but it's an improvement of less than 1%, and when your renders are taking 30+ms there are probably other things you should be looking at :P Also, unless I'm misunderstanding the README, using the plugin introduces the huge caveat of breaking code that uses "restricted names" (certain names of Array functions) - the example given is a class that defines a map() function, which apparently would cause some kind of failure. In larger codebases where you don't control all code used in production this seems like a big problem.
ballenf 9y ago
To the extent this tool will make it appear that there is less usage of functional JS patterns browser vendors deciding how to optimize their engines, I'm not a fan. Compiling away a useful feature or pattern just because it's not yet optimized creates a risk of a self-fulfilling prophecy. Obviously this is not a zero-sum game and optimizing for one pattern doesn't necessarily mean that something else must suffer, but prioritization of what to optimize is sometimes based on instrumentation measuring deployed usage and not just artificial benchmarks. The performance gap between a `for` loop and and a `.forEach` (also map) is much narrower than it used to be, and that is very encouraging.
city41 9y ago
It’s seems like it does harm in JS environments that have JITs. But it would be interesting in strictly interpreted environments. Some devices run JS but disallow JIT due to security concerns.

vzhou842 9y ago

Agreed for the most part - this realistically does not have a good generalized use case. IMO the only real harm is the slightly larger bundle, though - I think the extra build time is negligible and you could just disable this optimization when developing. My main motivation for building this was to make a better way to use an optimization library like fast.js (https://github.com/codemix/fast.js https://github.com/codemix/fast.js), which inspired faster.js. A huge issue with the fast.js library is that you have to rewrite your entire codebase in order to use it, whereas enabling or disabling faster.js is a one line change.

rococode 9y ago

I agree, while this is a cool idea it doesn't seem to be useful beyond being a proof of concept of an optimization technique. For example, my browser rendered the faster.js version 50ms slower at this point: https://i.imgur.com/G5b10Ns.jpg https://i.imgur.com/G5b10Ns.jpg. It does appear to perform better in the long run (https://i.imgur.com/u3ApYYl.jpg https://i.imgur.com/u3ApYYl.jpg) but it's an improvement of less than 1%, and when your renders are taking 30+ms there are probably other things you should be looking at :P Also, unless I'm misunderstanding the README, using the plugin introduces the huge caveat of breaking code that uses "restricted names" (certain names of Array functions) - the example given is a class that defines a map() function, which apparently would cause some kind of failure. In larger codebases where you don't control all code used in production this seems like a big problem.

ballenf 9y ago

To the extent this tool will make it appear that there is less usage of functional JS patterns browser vendors deciding how to optimize their engines, I'm not a fan. Compiling away a useful feature or pattern just because it's not yet optimized creates a risk of a self-fulfilling prophecy. Obviously this is not a zero-sum game and optimizing for one pattern doesn't necessarily mean that something else must suffer, but prioritization of what to optimize is sometimes based on instrumentation measuring deployed usage and not just artificial benchmarks. The performance gap between a `for` loop and and a `.forEach` (also map) is much narrower than it used to be, and that is very encouraging.

city41 9y ago

It’s seems like it does harm in JS environments that have JITs. But it would be interesting in strictly interpreted environments. Some devices run JS but disallow JIT due to security concerns.