[elm-discuss] Re: Elm Generated Files are Quite Large

[Austin Horning]

Yes, I know. I was just commenting on the fact that the two are often(not 
always) intertwined. If you are careful in the way you go about it you can 
implement dead code elimination in such a way that you also get dead code 
identification almost for free.

On Monday, August 8, 2016 at 8:59:22 PM UTC-7, Austin Horning wrote:
>
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Elm Generated Files are Quite Large

[Austin Horning]

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Elm Generated Files are Quite Large

[Max Goldstein]

Dead code removal aka tree shaking would be done with knowledge of Elm's 
type system and call graph. This is knowledge that uglify and similar 
programs don't have access to. That's why people are hoping it will make a 
difference, although there's no definitive evidence yet because the feature 
hasn't been implemented.

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Elm Generated Files are Quite Large

[Robin Heggelund Hansen]

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Elm Generated Files are Quite Large

[Richard Feldman]

Yep! Preliminary work for dead code elimination has been done for awhile 
, 
but finishing it has never been justifiable as the next priority.

I honestly doubt it'll be worth prioritizing in the next few months 
either...the thing is, it's the sort of thing most people want less than 
things like server-side rendering or better debugging capabilities.

It'll be the most important thing someday, but probably not soon. :)

On Monday, August 8, 2016 at 8:59:22 PM UTC-7, Austin Horning wrote:
>
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.