You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried this with node-minify, which uses uglify-js under the hood. It achieves decent compression (50%), but minimal speed-up.
I tried removing the run-time type-checks for assignment: this gave a decent reduction in size (compressed and uncompressed), but no significant improvement in runtime (for Hailstone sequence test).
I considered removing unused variables, but I can see from VS Code highlighting that there aren't that many.
Significant gains in speed will require more complex optimisation; obvious candidates are:
Unboxing of ArkNull, ArkBoolean, ArkNumber, ArkString and ArkFn.
Relatedly, reducing the number of JavaScript function calls per Ursa function call.
Both of these would be likely to be necessary in any compilation scheme, as it's hard to imagine a third-party optimisation pass that would supply these optimisations automatically, unless by compiling Ursa to a language sufficiently similar that has its own optimising compiler; e.g. Crystal.
On the plus side, it should be very quick to whip up back-ends targeting other high-level languages, so it would be cheap to make experiments like this.
The text was updated successfully, but these errors were encountered:
I tried this with node-minify, which uses uglify-js under the hood. It achieves decent compression (50%), but minimal speed-up.
I tried removing the run-time type-checks for assignment: this gave a decent reduction in size (compressed and uncompressed), but no significant improvement in runtime (for Hailstone sequence test).
I considered removing unused variables, but I can see from VS Code highlighting that there aren't that many.
Significant gains in speed will require more complex optimisation; obvious candidates are:
ArkNull
,ArkBoolean
,ArkNumber
,ArkString
andArkFn
.Both of these would be likely to be necessary in any compilation scheme, as it's hard to imagine a third-party optimisation pass that would supply these optimisations automatically, unless by compiling Ursa to a language sufficiently similar that has its own optimising compiler; e.g. Crystal.
On the plus side, it should be very quick to whip up back-ends targeting other high-level languages, so it would be cheap to make experiments like this.
The text was updated successfully, but these errors were encountered: