Please improve gen js

You can disable loop unrolling with -D loop_unroll_max_cost=0

1 Like

why not make this options as default?

because this -D XXXX have no where to find documents .

I think unrolling is actually considered as an “improvement” (towards performance)

1 Like

I don’t think it’s good idea to unroll,it’s make codes too big.

You can find it in haxe --help-defines

loop-unroll-max-cost      : <cost> Maximum cost (number of expressions *
                             iterations) before loop unrolling is canceled.
                             (default: 250)

Help defines being mentioned in haxe --help.

And yes loop unrolling helps performances, sure the code is less pretty, but the js interpreter doesn’t care :wink:

2 Likes

Information on compiler flags is also in the manual Global Compiler Flags - Haxe - The Cross-platform Toolkit

You can also use a variable instead of a hard-coded value

var x = 6;
for (i in 0...x) ...
2 Likes

I did a quick search on what the current state of JS engines is in regards to loop unrolling. According to 1039458 - Unroll tight loops Firefox can in theory do it itself but it’s not activated by default. Didn’t find anything about V8 but according to performance - JavaScript - Are loops faster than discretely writing line-by-line? - Stack Overflow it at least didn’t yet happen mid 2016.
Looks like it does indeed still make sense to unroll loops for JS.
Does not seem to make sense for C++ at all though, this basically just hides information from clang/gcc/msvc which all can do loop unrolling themselves and can combine it with other optimizations in fancy ways. Probably the same for Java and C# but I don’t know for sure and I don’t care enough for it to have a closer look.

PS: Please don’t use a variable for your loop bounds - if anything it’ll just make things slower.

2 Likes

It depends. For instance, it’s probably possible to construct cases where the constant index makes it possible for a closure call to be inlined. Some optimizations like that are only possible at higher-level.

Whether or not that actually happens in real code is another question though. We could indeed consider having this optimization off by default on targets that have good native (JIT) compilers.

Interesting, I thought about whether unrolling would allow further optimizations like that but couldn’t come up with any. Thanks!