Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's a lot of magic going on in this generated code that people keep getting wrong.

First and foremost, generating a 5 line function whose input/output types are fixed will almost certainly result in the function being inlined, where meaningful to do so, by any modern JIT.

For that reason, the analysis of the bind() variants in this article are probably wrong: each variant has a fixed set of types, and doesn't fuck around with variable length argument lists, leading to simpler analysis, which leads back to the previous point.

In both these cases, after gzip, the presence of the functions is almost certainly negligible. In any case, optimizing the cases above prior to output is low-hanging fruit that the team probably just haven't gotten around to yet.

The code is doing some annoying things, though. It looks like it's extending the build in JS objects with its own functions.



> In both these cases, after gzip, the presence of the functions is almost certainly negligible.

and

> In any case, optimizing the cases above prior to output is low-hanging fruit that the team probably just haven't gotten around to yet.

Are both huge assumptions. What you're not considering is that as the complexity of the program grows beyond a 'Hello World' to a complex web app, the runtime of 17K lines may balloon further. You have no idea what efficiency they already built in.

What is more telling is that the non-runtime code was much more verbose. If you have a complex app that is already 17K lines, you might see that balloon to 100K lines.

You can't tell until you try and my intuition tells me that my app based on MooTools or JQuery is going to be much leaner, faster, just as easy to maintain, and I don't have to compile anything.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: