Significant performance regression

[kg]

I updated to the latest revision of the spec and ml-proto is much slower than it used to be. The NBody test (https://github.com/WebAssembly/ilwasm/blob/master/third_party/tests/NBody.cs) now utilizes ~100% cpu for multiple seconds while running; it used to run at a reasonable speed.

Do we care about the performance of ml-proto? Overly slow execution will hinder our ability to iterate and bias us away from real-world tests, I think.

[lukewagner]

I think the default changed to building unopt builds (they have usable stack traces); so I'd try make opt. But in general, we've collectively agreed on a few occasions that the goal of ml-proto isn't performance, it's specifying behavior cleanly. There's a lot of O(n) operations in there that would be O(1) in a real interp.

[jcbeyler]

I agree. I think the goal should never be about performance, it does not mean that there could be work to make it faster but that should never be a decision about to specify cleanly something or not.

As the other projects that take S-Expression and try to generate assembly move forward, we'd have a better view of problems of taking SWasm and generating code and with the VMs (including the V8 one) we'd see the performance problems when running wasm

[sunfishcode]

Can you confirm whether using an optimized build runs with sufficient performance?

[lukewagner]

Assuming resolved by either (1) opt builds are faster, (2) the point of the spec ref interp is not perf.