Skip to content

What about tree shaking like in Dart to make compiled files smaller? #259

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
timfayz opened this issue Jul 17, 2015 · 6 comments
Closed

What about tree shaking like in Dart to make compiled files smaller? #259

timfayz opened this issue Jul 17, 2015 · 6 comments

Comments

@timfayz
Copy link

timfayz commented Jul 17, 2015

Hello, today I've tried your package and it is incredible! Really good job!) Included gopherjs build ... -w works very-very good! However, the problem is the compiled file size. It's too big (consider mobile phones with 600Mhz processors that will hardly parse 300kb of gzipped archive into > 1mb files). I know that there is no way without constant overhead to ensure compliance with the Go specification. However look at Dartlang.
$ dart2js main.dart

import 'dart:html';

void main() {
  var count = querySelector('body');

  for (int i = 0; i < 4; i++) {
    count.text = '${i}';
    print('hello ${i}');
  }
}

The result: out.js takes 0.069 MB without gzip and minifying.

Now the same version with Gopherjs and dom package:
$ gopherjs build main.go

package main

import (
    "honnef.co/go/js/dom"
    "fmt"
)

var document = dom.GetWindow().Document().(dom.HTMLDocument)

func main() {
    body := document.QuerySelector("body");
     for i := 0; i < 4; i++ {
         body.SetTextContent(fmt.Sprint(i));
         fmt.Printf("hello %v", i);
     }
}

The result: main.js takes 1.1 MB without gzip and minifying.

As far as I understand this good result is possible due to tree shaking.

Tree shaking gets rid of the stuff you don’t need.
slider-tree-example

If the Dart team have done it, you can do as well..I think. What about including in the build only what is actually used in the source code?
@timfayz timfayz changed the title What about tree shaking method to make compiled gopher smaller? What about tree shaking like in Dart to make compiled files smaller? Jul 17, 2015
@dmitshur
Copy link
Member

Is "tree shaking" the same thing as "dead code elimination"?

If so, GopherJS already does that, but it can't do it as thoroughly as one might hope due to reflection - it's hard to know in advance what may or may not be used via reflection (see related issue #136). There's an issue to perform more aggressive DCE, see #186, which seems like the best hope at helping with file sizes (with some tradeoffs).

@timfayz
Copy link
Author

timfayz commented Jul 17, 2015

I think yes. I very hope the author implement it very soon and results will satisfactory. Also I'm a little bit confused why the go-js-dom isn't part of gopherjs repository/organization.

@dmitshur
Copy link
Member

I very hope the author implement it very soon and results will satisfactory.

Me too. If I'm not mistaken, aggressive DCE (#186) is @neelance's current highest priority goal for GopherJS.

Also I'm a little bit confused why the go-js-dom isn't part of gopherjs repository/organization.

@dominikh can comment on that. But it's considered the canonical DOM package for GopherJS, as can be seen here.

@dominikh
Copy link
Member

Regarding "tree shaking"/dead code elimination: Like @shurcooL said, GopherJS does have DCE, but due to the way Go's reflection works, it's quite limited. Reflection allows access to all exported methods of a type, so all types used in those methods in turn cannot be eliminated. Although #186 could address that.

However, that still wouldn't help with e.g. my js/dom package, as this one suffers from a different problem: Each kind of DOM element has its own type and methods. At compile time, we don't know which kinds of elements we might encounter at runtime, so almost nothing of the package can be eliminated.

why the go-js-dom isn't part of gopherjs repository/organization

It's not part of the gopherjs repository because that's just the compiler/stdlib adjustments. It's not part of the GopherJS organization because I believe in an open and independent ecosystem and don't think that everything GopherJS-related has to live in that organisation.

@neelance
Copy link
Member

All said above is correct. GopherJS already features dead code elimination and there will be a more aggressive version in the future (#186).

@kalopsia You are mentioning slower mobile phones. Do you have some concrete numbers? I think even a 600MHz processor should be able to decompress 1MB in just a few milliseconds.

@timfayz
Copy link
Author

timfayz commented Jul 21, 2015

Thanks for reply! I got it. Now I can close the issue.

You are mentioning slower mobile phones. Do you have some concrete numbers? I think even a 600MHz processor should be able to decompress 1MB in just a few milliseconds.

Nope, don't worry, it's purely my assumption)

@timfayz timfayz closed this as completed Jul 21, 2015
@cliveb cliveb mentioned this issue Jun 2, 2016
Closed
@flimzy flimzy mentioned this issue Jul 10, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@neelance @dominikh @dmitshur @timfayz