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

The difference with C is that with a good linker, functions you don't call are removed from the resulting binary (or are maybe not even in the binary if you are dynamically linking to the c runtime).

With javascript however, if you import a hypothetical "math.js" instead of just "sin.js", "cos.js" or "tan.js", then you'll need to download and evaluate a whole bunch of javascript that you might not need.

I'm not defending javascript, because I dislike it and avoid it where possible, but I can understand some of the reasons why short, specific modules came about.



Webpack 2 (probably the closest thing to a JS linker) can do that same tree shaking.


what you describe is the "-flto" option in GCC and I believe the equivalent in JS is donr by Google Closure compiler.


He described not Link Time Optimization (-flto), but the very basic linker functionality: to only include required functions. C/C++ has a weird compilation model where each source file is translated to machine code separately, with placeholders for unknown function addresses. Thus it is trivial to take only required functions.

-flto, on the other hand, allows to reverse this process to allow interprocedural optimization across different translation units.


@TickleSteve below me: "without this, removal is only performed within the compilation-unit"

Not quite. When you link to a static library (.a) with lots of .o object files in it, only those object files will be linked that are actually used by your program.

I first learned about this when I looked at the source of dietlibc, and wondered about every function being in a separate file. That enables the aforementioned trivial optimization, even without -flto.


I saw that discussion years ago about the G++ String implementation. That was a big .o file.


Thanks for the correction. Didn't know that.


He's describing unused-function removal... which "-flto" is the correct option to use (on GCC). like you say, without this, removal is only performed within the compilation-unit, but my statement was quite correct.

@majewsky: what you're describing is more akin to "-ffunction-sections" and "-gc-sections" which will split ewach function into a separate section and garbage-collect those sections.




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

Search: