Make compilation faster about wazero HOT 5 OPEN

Thanks for your response. Firstly I want to say how much I appreciate the wazero project, and understand the limitations it is under and think y'all are doing a fantastic job.

Hopefully, given the modularity of the new compiler, this feature could be feasible.

Opening this issue not as a bug but just as a mark of interest in this aspect of the compiler.

Given the varied use cases of wasm, I hope in the future wazero can provide an option for use cases that prefer quick compilation over quick runtime performance.

I will experiment with the interpreter and report back with hard numbers later but I think the interpreter seemed to take as much time as the v1.7.0 compiler.

If the interpreter can work for fast startup then this is fine for me!

from wazero.

so basically, we have no resources or plan to introduce any other complexity in compiler implementation. In fact, as you can see #2214, there's really plenty of rooms for making the current compiler faster. You can try and see where is the bottleneck of compilation, and if you can contribute as well. At least, we should be able to make our current compiler as fast as wasmtime in terms of compilation performance (not runtime perf!).

Given that, I am changing the title of this issue to something like optimizing compilation perf

from wazero.

wazero is maintained by a small team, so when the new compiler was introduced, it was decided to renove the old compiler (which was a totally different code base).

The new compiler is more modular, so it may be possible to disable certain optimization passes (I'll leave it to @mathetake to comment on that). It's also a recent codebase, and there might be some opportunity to optimize it. Having said that, it's probably unrealistic to expect it to become as fast as the previous compiler was.

You have two mitigation strategies at your disposal:

1. cache the compilation result
2. use the interpreter

Other than that, if you can find (or fix!) a bottleneck in the compiler (pprof is highly recommended), we're enthusiastic about any improvements.

from wazero.

As promised here are my findings running against a 65Mb wasm file on my Macbook Air M2 (Arm64):
(these results include compiling and executing the wasm - i suspect execution speed is negligible)

v1.6.0 compiler   : 2.49s
v1.6.0 interpreter: 1.866s

v1.7.0 compiler   : N/A
v1.7.0 interpreter: 2.087s

v1.7.1 compiler   : 26.134s
v1.7.1 interpreter: 1.967s

What we can draw is that the the compiler is about one order of magnitude (10x) slower than the previous 1.6.0 compiler.

However, that being said, I was wrong when I created the issue, and must have had a misconfiguration on my end: The interpreter is only marginally, and arguably negligibly slower.

Previous to v1.7.X there was little reason to use the interpreter over the compiler except for supporting more architectures.
Now I think it would be reasonable to add to the documentation the differences in startup time, and market the interpreter setup as the solution for programs that need fast... Well interpretation times.

This advice could be revisited if and when optimization levels become a thing.

In the meantime, I am satisfied using the interpreter.

from wazero.

Turns out the interpreter does not scale very well. For programs that I can compile and run quickly with v1.6.0 (~5s), with the interpreter it takes 30+ seconds on both v1.6.0 and v1.7.x of wazero.

An option similar to zig's releaseFast flag, where we could disable a lot of the optimizations and achieve closer to the compilation speed of v1.6.0 would be beneficial.

TLDR: Contrary to what I believed before, the interpreter is not a silver bullet as it does not scale for complex tasks.

from wazero.