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.
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.
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.
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.
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.
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: Dec 23 2024 at 12:05 UTC