3 ms·

Can anyone speak to the trade-off in file size, for non-trivial codebases? There is a stated design goal of "small size of generated code", but the default snip

by Cyranix 12y ago

Can anyone speak to the trade-off in file size, for non-trivial codebases? There is a stated design goal of "small size of generated code", but the default snippet in the playground introduces quite a large amount of boilerplate. Is the penalty on file size fairly front-loaded or does the generated code scale horribly?

shurcooL 12y ago
The thing is that if you want to compile a single fmt.Println("Hello") line, that will produce a large output because of what's needed to support it, including dealing with Go/JS types like bytes, runes, slices, standard library ("fmt" and things it imports), etc. That part is constant. Once you write more code, the generated output will grow very gracefully as expected. The output is quite large (order of 1~2 MB), even when minified, so it might not work well yet for user facing sites with huge traffic. That could be an ongoing improvement effort for GopherJS to benefit from. However, for smaller sites or offline utilities it works absolutely great.
nknighthb 12y ago
Annoyingly but predictably, I don't really have any nontrivial code of my own around that doesn't violate any of the (entirely reasonable, except for x509) constraints. GopherJS happily compiles itself, however. The raw source code looks to be about 250KB. The native binary ends up 7.7MB, and the unminified js is 3MB. A pass through UglifyJS with default options reduces that to 1.7MB (I have not tested the result): ~/gocode/bin$ ls -lh *gopher* -rwxr-xr-x 1 nknight staff 7.7M Oct 14 14:02 gopherjs -rw-r--r-- 1 nknight staff 3.0M Oct 14 14:32 gopherjs.js -rw-r--r-- 1 nknight staff 233K Oct 14 14:32 gopherjs.js.map -rw-r--r-- 1 nknight staff 1.7M Oct 14 14:41 min-gopherjs.js ~/gocode/bin$ Edit: Oh, and the playground example minifies to 300KB: ~/gjstest/playground$ ls -lh total 1784 -rw-r--r-- 1 nknight staff 194B Oct 14 14:05 main.go -rw-r--r-- 1 nknight staff 536K Oct 14 14:53 main.js -rw-r--r-- 1 nknight staff 42K Oct 14 14:53 main.js.map -rw-r--r-- 1 nknight staff 300K Oct 14 14:54 min-main.js ~/gjstest/playground$
- nulltype 12y ago
  What about after gzip?
  - nknighthb 12y ago
    About what you'd expect, the playground sample drops to 75KB, and the compiler to 424KB. (Also the native binary gzips to 2MB.)
    - shurcooL 12y ago
      Very nice finding!
bitg 12y ago
The original output is very large but when gzipped it's surprisingly small. For example an app in my framework that gopherjs produces is like 1.2MB minified, but the gzipped one is just over 200kb, so no problem.
- cromwellian 12y ago
  Download size isn't the only issue. Larger scripts are slower to parse and startup, slow down debugging tools, inhibit JS VM optimizations and use up more heap in general. This may not matter on desktop intranets, but it will matter on the mobile web.

by Cyranix 12y ago

shurcooL 12y ago

The thing is that if you want to compile a single fmt.Println("Hello") line, that will produce a large output because of what's needed to support it, including dealing with Go/JS types like bytes, runes, slices, standard library ("fmt" and things it imports), etc. That part is constant. Once you write more code, the generated output will grow very gracefully as expected. The output is quite large (order of 1~2 MB), even when minified, so it might not work well yet for user facing sites with huge traffic. That could be an ongoing improvement effort for GopherJS to benefit from. However, for smaller sites or offline utilities it works absolutely great.

nknighthb 12y ago

Annoyingly but predictably, I don't really have any nontrivial code of my own around that doesn't violate any of the (entirely reasonable, except for x509) constraints. GopherJS happily compiles itself, however. The raw source code looks to be about 250KB. The native binary ends up 7.7MB, and the unminified js is 3MB. A pass through UglifyJS with default options reduces that to 1.7MB (I have not tested the result): ~/gocode/bin$ ls -lh *gopher* -rwxr-xr-x 1 nknight staff 7.7M Oct 14 14:02 gopherjs -rw-r--r-- 1 nknight staff 3.0M Oct 14 14:32 gopherjs.js -rw-r--r-- 1 nknight staff 233K Oct 14 14:32 gopherjs.js.map -rw-r--r-- 1 nknight staff 1.7M Oct 14 14:41 min-gopherjs.js ~/gocode/bin$ Edit: Oh, and the playground example minifies to 300KB: ~/gjstest/playground$ ls -lh total 1784 -rw-r--r-- 1 nknight staff 194B Oct 14 14:05 main.go -rw-r--r-- 1 nknight staff 536K Oct 14 14:53 main.js -rw-r--r-- 1 nknight staff 42K Oct 14 14:53 main.js.map -rw-r--r-- 1 nknight staff 300K Oct 14 14:54 min-main.js ~/gjstest/playground$

nulltype 12y ago
What about after gzip?
- nknighthb 12y ago
  About what you'd expect, the playground sample drops to 75KB, and the compiler to 424KB. (Also the native binary gzips to 2MB.)
  - shurcooL 12y ago
    Very nice finding!

bitg 12y ago

The original output is very large but when gzipped it's surprisingly small. For example an app in my framework that gopherjs produces is like 1.2MB minified, but the gzipped one is just over 200kb, so no problem.

cromwellian 12y ago
Download size isn't the only issue. Larger scripts are slower to parse and startup, slow down debugging tools, inhibit JS VM optimizations and use up more heap in general. This may not matter on desktop intranets, but it will matter on the mobile web.