Improved function arity analysis

[vouillon]

Addresses #594

The analysis is a bit costly, so we want to see whether this should be enabled by default.

There is also the option to make a coarser analysis (propagation information about what the functions returns but not through function parameters).

currently	faster analysis	full analysis
5.24 sec	5.19 sec: 1.01x faster	5.11 sec: 1.03x faster

[hhugo]

@vouillon, I've rebased the branch and force-pushed after merging #1384

[hhugo]

I don't know how to read the timing in the description. What is it about ? Why is the "full analysis" faster that the "faster" one ?

[vouillon]

I don't know how to read the timing in the description. What is it about ? Why is the "full analysis" faster that the "faster" one ?

This is the timing of the generated code, when executing the following command:

node ocamlc.js -c ~/js_of_ocaml/benchmarks/sources/ml/*.ml

So, a more precise analysis yields a significant gain.

Compiling ocamlc.byte takes about 12s. The faster analysis adds about 0.35s. The full one adds about 0.8s.

[hhugo]

How is the size affected ? how many extra direct call are generated ?

[hhugo]

We could enable the full analysis with -O3 only

[vouillon]

How is the size affected ? how many extra direct call are generated ?

The code is about the same size. About 0.25% larger since we use a somewhat verbose notation for best performances:a[7].call(null, e1, ...,en). Indeed, a[7](e1, ..., en) would be interpreted as a method call on array a which is slower than using caml_calln. I tried patterns like (0||a[7])(...) or (0,a[7])(...) as a workaround, but they still seems slower than using call.

There are not that many additional extra direct calls but I think they are more likely to be performed repeatedly.

	currently	faster analysis	full analysis
Code size	1912637	1917311	1917226
Direct calls	25883	+1409	+ 1854

[hhugo]

I've rebased your branch and make fast depend on profile (o1,o2,o3)

[hhugo]

@vouillon, what do you want to do with this ?

[hhugo]

I've rebased the PR again

[hhugo]

@vouillon, this is the last PR I'd like to sort out before the next release (see https://github.com/ocsigen/js_of_ocaml/milestone/10).
Should we merge or not ?

[vouillon]

@hhugo I think it is ready

[hhugo]

@vouillon, can you provide some reference mentioning this optimization. I did some test and it seems to show the opposite.

[vouillon]

I don't have any reference, but without this, the improved analysis resulted in slower code.
I just tried is compiling ocamlc.byte (dune exec -- js_of_ocaml --opt 3 which ocamlc.byte -o /tmp/ocamlc.js).
And then running it on some ml source files:

time node /tmp/ocamlc.js -c ./benchmarks/sources/ml/*.ml ./benchmarks/sources/ml/*.ml ./benchmarks/sources/ml/*.ml

This optimization makes close to a 8% performance improvement on my machine.

[hhugo]

What ocaml version do you use ? it seems that ocamlc no longer works when compiled to js due to ocaml/ocaml#11997 (since OCaml 5.1). The reason is that Reloc_literal can now contain floats that jsoo doesn't want to marshal.

[vouillon]

I tried with Ocaml 4.14.0.

[hhugo]

This optimization makes close to a 8% performance improvement on my machine.

Results are too noisy on my laptop but I can see some improvements indeed.

[vouillon]

I'm using python3 -m pyperf system tune to reduce the noise.