Jsoo webgl example : seconds to compile

Learning
1

Is js_of_ocaml/examples/webgl at master · ocsigen/js_of_ocaml · GitHub supposed to take seconds to compile on an INCREMENTAL change ?

I.e

  1. dune build
  2. modify ml file
  3. time dune build
time dune build
                                    
real	0m3.029s
user	0m3.154s
sys	0m0.507s

3 seconds is very surprising to me; I was expecting low two-digits milliseconds, for incremental compile on a ~300 line ML file

Ideas on (1) reducing compile time or (2) benchmarking the compile time ?

2

If I remember correctly the js_of_ocaml compiler (or linker, technically) does global program optimisations to remove as much dead code as possible. This means that even an incremental change needs to go over the whole project again. I don’t know whether three seconds is a reasonable time for a project of this size or not though.

3

This example seems to use its own dune file to invoke js_of_ocaml. Use the built-in dune support.

@vlaviron is correct however if you build with dune in dev profile, jsoo separate compilation should be enabled. This doesn’t perform whole program optimisations and should yield shorter compilation times.

2 Likes
4 
time dune build
Error: The package fso does not have any user defined stanzas attached to it.
If this is intentional, add (allow_empty) to the package definition in the
dune-project file
-> required by _build/default/fso.install
-> required by alias all
-> required by alias default
                                              
real	0m1.696s
user	0m1.819s
sys	0m0.314s


cat webgl/dune 
(executables
 (names webgldemo)
 (modes js)
 (preprocess (pps js_of_ocaml-ppx))
 (libraries js_of_ocaml-lwt)
 )

Are there more optimizations that can be done to the buildtime (or also how to get rid of the warning / error).

5

For the error, I think you need a public_name and/or package in your stanza.
If you ask this question because you find that the compilation time is too long for a development workflow, you can use dune build @check (or even dune build @check -w) to check that everything typechecks, which should be much faster. But it will not give you the .js output.

6

On my laptop,

  • recompiling webgldemo.cmo takes almost 1s.
  • recompiling webgldemo.cmo.js takes ~300ms
  • linking the final js takes ~250ms
$ (cd _build/default && time ~/.opam/4.14.0/bin/ocamlc.opt -w @1..3@5..28@30..39@43@46..47@49..57@61..62-40 -strict-sequence -strict-formats -short-paths -keep-locs -w +a-4-40-41-42-44-48-58-66-70 -g -bin-annot -I examples/webgl/.webgldemo.eobjs/byte -I ~/.opam/4.14.0/lib/lwt -I lib/js_of_ocaml/.js_of_ocaml.objs/byte -I lib/lwt/.js_of_ocaml_lwt.objs/byte -I lib/runtime/.jsoo_runtime.objs/byte -intf-suffix .ml -no-alias-deps -opaque -o examples/webgl/.webgldemo.eobjs/byte/dune__exe__Webgldemo.cmo -c -impl examples/webgl/webgldemo.pp.ml)

real	0m0,962s
user	0m0,898s
sys	0m0,062s
1 Like
7

I’m a bit new to ocaml terminology:

1. recompiling webgldemo.cmo takes almost 1s.
2. recompiling webgldemo.cmo.js takes ~300ms
3. linking the final js takes ~250ms

Is 1: *.ml → bytecode (i.e. standard ocaml → bytecode pipeline)
Is 2: bytecode → js (actual js of ocaml)
Is 3: ‘tree shaking’ ?

8

1 and 2, you’re correct.
3, it’s not really tree shaking. It is concatenating all files and merging source maps if any. The next release of jsoo will be able to omit unused compilation units from libraries similar to ocamlc. (Maybe you can call that tree shaking)

Some dead code elimination happens in (2).

“Tree shaking” happens when doing whole program compilation with jsoo