Bloated Javascript from dartc

[Duane Sand]

The dartc compiler currently turns the 5-line 'Hello Dart' example
into a 225K-line Javascript program totalling 9.2 Mbytes. Almost all
of that is for unused functions from Dart's standard libraries. Dartc
turns the 300-line spirodraw example into 1530 lines of Javascript,
plus 168K lines of standard libraries.

This first version of dartc is adequate for toy examples, but it is
orders of magnitude away from what will be needed for practical web
use of Dart in browsers that do not include a Dart VM.

How will the 5x expansion factor for individual functions be reduced?
How will the redundant JS downloads of Dart standard libraries and
website-specific libraries be reduced?

[John Tamplin]

First, this is a work in progress.  Some of the things that were recently added to the language caused a lot of bloat and we need to work on improving the compiled output.  We also need to take better advantage of type information than we currently do.

Second, are you using --optimize?

--
John A. Tamplin
Software Engineer (GWT), Google

[Duane Sand]

On Oct 12, 8:35 am, John Tamplin <j...@google.com> wrote:

Adding --optimize helped somewhat; thanks.
This significantly reduced the bloat from 9.2Mbytes to 0.19Mbytes,
and from 225K lines down to 14600 statements.
But the number of included functions is still high at 2645.

I couldn't easily tell whether this helped the size of the original
Dart functions.
The minifier renaming done by the closure compiler made it hard to
find and distinguish those things from all the standard library
things. Debugging this form would be quite hard, too.

Seems like there needs to be some way to keep the libraries separately
translated and separately downloaded as js, to eliminate redundant
downloads etc.

[Eli Brandt]

Hi, Duane, dartc --optimize --human_readable_output is not as small as the minified code, but you may find it useful for debugging.

Eli

[Duane Sand]

> Hi, Duane, dartc --optimize --human_readable_output is not as small as the
> minified code, but you may find it useful for debugging.
>
> Eli

I didn't figure out how to apply dartc directly to the .dart files of
the spirodraw example. But I did find how to get htmlconverter to
pass this extra option on to dartc. Do

python client/tools/htmlconverter.py client/samples/spirodraw/
spirodraw.html -o out/ --extra-flags=--human-readable-output --
optimize

Note that the option name has dashes, not underscores. And the extra
-- after the --extra-flags= is required.

The result was obsfucated by renamed verbosity rather than by renamed
2-letter names. Quite hard to read; I would not call it human
readable.

I think the 5x expansion in lines of code was reduced to near 1x, but
each single-statement line was very wide with the gloriously long
names.

What I originally hoped for, was that the dartc tool produced simple
javascript text somewhat close to what a human programmer would have
coded by hand from the original dart text. Ie drop type info, restyle
the function defs, and hide the global scope, and not much else.
Maybe dartc can evolve to that someday.

From the dartc'd demo, I hoped to learn more about the semantic
differences between the languages,
and what kind of semantic-gap overhead is incurred by translating dart
to javascript, compared to direct execution via dartvm,
and how practical the auto-javascript alternative will be when dart
page pages are viewed by non-dart browsers.

[John Tamplin]

On Wed, Oct 12, 2011 at 7:54 PM, Duane Sand <duane....@gmail.com> wrote:

What I originally hoped for, was that the dartc tool produced simple

javascript text somewhat close to what a human programmer would have
coded by hand from the original dart text.  Ie drop type info, restyle
the function defs, and hide the global scope, and not much else.
Maybe dartc can evolve to that someday.

Some things, such as reified generics, x is Y tests, named/optional parameters, and calling through getters (ie, Function bar get() => ...; foo.bar(x) calls the function returned by bar passing x, rather than calling the method bar) require fairly convoluted JS to implement.  The compiler will be able to remove some of this as it gets smarter about tightening types, supporting method cloning (ie, generate two methods of foo, each specialized to different input types and call the appropriate one where known), and other optimization techniques.

[Wilbert]

With --optimize option, it takes longer time to convert the 9 lines of
html to dart format.
It also bloat the file size with option of --extra-flags --human-
readable-output.
However, when compiling the isolate_sample.html, first, it failed to
compile.
Instead, it showed up the java.lang.OutOfMemoryError: Java heap space.
java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap
space
at com.google.javascript.jscomp.Compiler.runCallable(Compiler.java:
628)
at
com.google.javascript.jscomp.Compiler.runInCompilerThread(Compiler.java:
573)
at com.google.javascript.jscomp.Compiler.compile(Compiler.java:555)
at com.google.javascript.jscomp.Compiler.compileModules(Compiler.java:
546)
at
com.google.dart.compiler.backend.js.ClosureJsBackend.compileModule(ClosureJsBackend.java:
344)
at
com.google.dart.compiler.backend.js.ClosureJsBackend.packageAppOptimized(ClosureJsBackend.java:
234)
at
com.google.dart.compiler.backend.js.ClosureJsBackend.packageApp(ClosureJsBackend.java:
628)
at com.google.dart.compiler.DartCompiler
$Compiler.packageApp(DartCompiler.java:669)
at com.google.dart.compiler.DartCompiler
$Compiler.compile(DartCompiler.java:126)
at com.google.dart.compiler.DartCompiler$Compiler.access
$200(DartCompiler.java:72)
at com.google.dart.compiler.DartCompiler.compileLib(DartCompiler.java:
999)
at com.google.dart.compiler.DartCompiler.compileLib(DartCompiler.java:
985)
at com.google.dart.compiler.DartCompiler.compileApp(DartCompiler.java:
926)
at
com.google.dart.compiler.DartCompiler.compilerMain(DartCompiler.java:
860)
at
com.google.dart.compiler.DartCompiler.compilerMain(DartCompiler.java:
847)
at com.google.dart.compiler.DartCompiler.main(DartCompiler.java:807)

Shall I config the memory allocation for jvm ?

Guo-Guang

On Oct 13, 8:29 am, John Tamplin <j...@google.com> wrote:

[Duane Sand]

Andrea Giammarchi's blog page
http://webreflection.blogspot.com/2011/10/what-is-wrong-about-17259-lines-of-code.html

has some useful-sounding comments on the form and size of the current
generated library code.
I recommend having a direct conversation with him.

[John Tamplin]

On Fri, Oct 14, 2011 at 3:05 PM, Duane Sand <duane....@gmail.com> wrote:

Andrea Giammarchi's blog page
 http://webreflection.blogspot.com/2011/10/what-is-wrong-about-17259-lines-of-code.html

has some useful-sounding comments on the form and size of the current
generated library code.

Looking at unoptimized output and complaining about things that the optimizer solves today seems to not be useful.  We have already said that the generated JS is bloated now, and it will get better.

 

I recommend having a direct conversation with him.

Given the tone of his post and the last couple of paragraphs in particular, it doesn't seem that it will be fruitful.