long compile times of FunctionalRecordUpdate

[mnegovanovic]

tmp $ time smltojs fru.sml [reading source file: fru.sml] [wrote JavaScript file: MLB/Js/fru-sml.js] [Created file run.html]

real 0m49.139s user 0m49.028s sys 0m0.037s

File located at: https://gist.github.com/DarinM223/7b55e617070969933f797053a7c15652

[mnegovanovic]

time smltojs src/shared/fru.sml [reading source file: src/shared/fru.sml] [wrote JavaScript file: src/shared/MLB/Js/fru-sml.js] [Created file run.html]

real 0m5.023s user 0m4.894s sys 0m0.130s

10x speed-up with recent HEAD ... can we go faster?

Regards

[melsman]

It's the optimiser:

bash-3.2$ SML_LIB=~/gits/mlkit/js ~/gits/mlkit/bin/smltojs -timings fru.sml && cat KITtimings
[reading source file:	fru.sml]
[wrote JavaScript file:	MLB/Js/fru-sml.js]
[Created file run.html]
[wrote compiler timings file: KITtimings]
Parse 0.012
Elab 0.026
CompileDec 0.042
ElimEq 0.001
OptLam 35.465
CheckLam 0.044
bash-3.2$ 

[melsman]

With inlining disabled, we get the following:

bash-3.2$ SML_LIB=~/gits/mlkit/js ~/gits/mlkit/bin/smltojs -maximum_inline_size 0 -timings fru.sml && cat KITtimings
[reading source file:	fru.sml]
[wrote JavaScript file:	MLB/Js/fru-sml.js]
[Created file run.html]
[wrote compiler timings file: KITtimings]
Parse 0.012
Elab 0.025
CompileDec 0.046
ElimEq 0.001
OptLam 0.041
CheckLam 0.055
bash-3.2$

[melsman]

It is possible to control the optimiser inliner locally by naming variables with a __noinline suffix. By playing around with this feature (e.g., renaming next to next__noinline) , I managed to decrease optimisation times drastically... The types do get large, though, so do try to resist printing the resulting intermediate expression (e.g., with -Pole)....

We could attempt to recognise that repeated inlining of small functions could cause term explosion. However, no matter what we do, in the present case, the types still explodes in size...