Stream: git-wasmtime

Topic: wasmtime / issue #3415 Poor performance compiling lots of...

Wasmtime GitHub notifications bot (Oct 04 2021 at 18:56):

alexcrichton opened issue #3415:

This issue is similar to #3414 where a fuzz-generated test case generated an odd-looking function which ended up taking a fair bit of time to compile.

This module: baz.wasm.gz takes ~20ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./baz.wasm
./target/release/wasmtime compile --disable-cache ./baz.wasm  0.03s user 0.02s system 200% cpu 0.022 total

With the multiplicative factors in fuzzing and multiple copies of this function being in the fuzz input, that generally accounts for the timeout when fuzzing. Like #3414 this is almost surely improved by the new register allocator but in the meantime we can probably do better at compiling this particular function.

Wasmtime GitHub notifications bot (Oct 04 2021 at 18:56):

alexcrichton labeled issue #3415:

This issue is similar to #3414 where a fuzz-generated test case generated an odd-looking function which ended up taking a fair bit of time to compile.

This module: baz.wasm.gz takes ~20ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./baz.wasm
./target/release/wasmtime compile --disable-cache ./baz.wasm  0.03s user 0.02s system 200% cpu 0.022 total

With the multiplicative factors in fuzzing and multiple copies of this function being in the fuzz input, that generally accounts for the timeout when fuzzing. Like #3414 this is almost surely improved by the new register allocator but in the meantime we can probably do better at compiling this particular function.

Wasmtime GitHub notifications bot (Nov 12 2021 at 04:06):

jlb6740 labeled issue #3415:

This issue is similar to #3414 where a fuzz-generated test case generated an odd-looking function which ended up taking a fair bit of time to compile.

This module: baz.wasm.gz takes ~20ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./baz.wasm
./target/release/wasmtime compile --disable-cache ./baz.wasm  0.03s user 0.02s system 200% cpu 0.022 total

With the multiplicative factors in fuzzing and multiple copies of this function being in the fuzz input, that generally accounts for the timeout when fuzzing. Like #3414 this is almost surely improved by the new register allocator but in the meantime we can probably do better at compiling this particular function.

Wasmtime GitHub notifications bot (Nov 19 2021 at 16:23):

alexcrichton labeled issue #3415:

This issue is similar to #3414 where a fuzz-generated test case generated an odd-looking function which ended up taking a fair bit of time to compile.

This module: baz.wasm.gz takes ~20ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./baz.wasm
./target/release/wasmtime compile --disable-cache ./baz.wasm  0.03s user 0.02s system 200% cpu 0.022 total

With the multiplicative factors in fuzzing and multiple copies of this function being in the fuzz input, that generally accounts for the timeout when fuzzing. Like #3414 this is almost surely improved by the new register allocator but in the meantime we can probably do better at compiling this particular function.

Wasmtime GitHub notifications bot (Apr 26 2022 at 15:00):

alexcrichton commented on issue #3415:

I'm going to close this given the discussion on https://github.com/bytecodealliance/wasmtime/issues/4060, these sorts of outliers are expected and eventually we'll want to tweak fuzzers to not generate these patterns of code.

Wasmtime GitHub notifications bot (Apr 26 2022 at 15:00):

alexcrichton closed issue #3415:

This issue is similar to #3414 where a fuzz-generated test case generated an odd-looking function which ended up taking a fair bit of time to compile.

This module: baz.wasm.gz takes ~20ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./baz.wasm
./target/release/wasmtime compile --disable-cache ./baz.wasm  0.03s user 0.02s system 200% cpu 0.022 total

With the multiplicative factors in fuzzing and multiple copies of this function being in the fuzz input, that generally accounts for the timeout when fuzzing. Like #3414 this is almost surely improved by the new register allocator but in the meantime we can probably do better at compiling this particular function.

Last updated: Oct 23 2024 at 20:03 UTC