Understanding Tree shaking in dart2js

[Sarat Adiraj]

Hi, 

Can someone help in briefly describing the tree shaking code path and if it is possible to disable tree shaking to allow full translation of the dart code into javascript ?

Thanks,

Sarat

[Günter Zöchbauer]

I don't know in detail but in general starting from your main() all code that is referenced somehow is kept and otherwise dropped.

Why would you want to keep code and force the browser to download it even when it is guarantied it will ever be executed because no code path leads to this code?

[Sarat Adiraj]

Hi Gunter,
My question is not aimed for browser usage or performance.
It is purely related to understanding how the tree shaking feature is designed in the compiler and if it was controlled by an internal compiler flag.
This will help in understanding what programming patterns are used in the compiler and if the features are designed in a modular fashion and if plug-ins can be implemented to enable or perform more analysis of the generated js output.
Thanks,
Sarar

To unsubscribe from this group and stop receiving emails from it, send an email to compiler-dev...@dartlang.org.

[Günter Zöchbauer]

You can disable tree-shaking for different parts of the code using the @MirrorsUsed annotation.

dart2js -h -v doesn't show an option to disable tree-shaking.

Using 

    pub build --mode=debug 

disables tree-shaking though.

[Günter Zöchbauer]

This might contain a few bits of information

http://blog.sethladd.com/2013/01/minification-is-not-enough-you-need.html

[Sarat Adiraj]

Thanks Günter for your prompt responses...

The link does not contain any info on the internal design of the tree shaking process.

I'm more interested in understanding the internals of the compiler , for eg., I would like someone to point to the dart file where the code for the tree shaking task

starts in the dart/sdk/lib/_internal folder.

[Florian Loitsch]

The compiler doesn't really implement "tree-shaking" but rather "tree-growing".

It starts by doing a fast diet-parsing which reads all the files and collects statics, classes and methods (without really looking into them). Then it finds the main-entry point `main` and resolves all identifiers. Using the data that was collected from the diet-parser it grows the reachable set of code. This is done in the enqueuer. Every method that is reached this way is then, in turn, resolved and the tree continues to grow until a fixed point is reached.

Note that in many cases dart2js has to be conservative: if it sees `o.foo` but doesn't exactly know what the type of `o` is, it needs to enqueue all possible `foo` methods. For this reason there is another tree-growing, when we actually build the code for every method. Starting, again, with `main` dart2js compiles every reachable method. At this point the generated code assumes that every marked class/method (from the resolution phase) is alive. However, it starts its own queue where it only puts elements (methods, classes, ...) that the code-generator itself determines to be reachable.

For example:

main() {

  if (false) print(new A());

}

In the resolver the class `A` would be marked as reachable, since there is an instantiation of it in the code.

However, the code-gen would do dead-code elimination and remove the call to the constructor. As such it would not appear in the final output.

Hope that helps.

[Sarat Adiraj]

Thanks Florian,

I have also noticed that the compiler has a flag called "isTreeShakingDisabled"  (trunk/dart/sdk/lib/_internal/compiler/implementation/compiler.dart) 

.I'm assuming that this flag gets set when mirrors is enabled on a class / element or if debug mode is set for the build. Could you shed some light on it's purpose and usage ?

Thanks,

Sarat