Dead code elimination also implies dead code identification which can help in adding compiler warnings for dead code. This is of course a completely seperate discussion, but dead code identification can be immensely useful as a compiler feature.
On Monday, August 8, 2016 at 9:52:44 PM UTC-7, Robin Heggelund Hansen wrote: > > I know I've told this to you earlier. But the Elm compiler generates code > in such a way that makes it VERY easy for Uglify to remove most (if not > all) unused code (especially libraries). I'm working on an Elm app right > now which has a bunch of libraries, and the size of the app is way smaller > than my Javascript React apps and previous Clojurescript apps (which uses > Google Closure as the compiler). > > I'm unconvinced that dead code removal in the compiler itself would make a > huge difference when minified. > > tirsdag 9. august 2016 05.59.22 UTC+2 skrev Austin Horning følgende: >> >> Using the latest version of elm, even the simplest of apps come out to >> greater than 7000 lines and 100kb of generated javascript. This seems to be >> because all imported libraries are included regardless of whether or not >> they are used, and upon digging into the generated code, it would seem that >> it would not be completely unreasonable to leave about half of that code >> unused even in larger projects. If elm employed some sort of pruning >> strategy to find and remove unused code at compile time, then thousands of >> lines could be removed from the generated javascript. There are a couple >> ways to go about this as far as I can see. >> >> The first would be to have a sort of lazy including strategy, which would >> build a sort of dependency tree as function calls are detected. This method >> has the advantage of being quick and more aware of the elm compilation >> process(being a part of the basic compilation process), which could lend to >> it being more extensible. >> >> The second strategy is to build the javascript as it is already done. >> Then make a few passes with another tool and remove dead code from the file >> in that fashion. This method might be slower, but it would not interfere >> with the current compilation process. >> >> Don't get me wrong. 100 kb is not that bad, and I certainly would not see >> this as a super high priority. The possibility is that if it could be >> incredibly small at compile time, it would be incredibly practical to embed >> elm apps everywhere(even multiple in one page, potentially). If the >> compiler was responsible, it would likely be much more efficient than >> UglifyJs(given the nature of JS) at dead code removal and the option to run >> through Uglify is still available. If I am a business and you tell me that >> I can save 90% on CDN costs and cut page load time in half(just in terms of >> download time) by switching to elm, that could be an incredibly convincing >> argument. >> >> Has anyone considered implementing something like this? >> > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
