Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minor instantiation benchmark updates #3790

Merged
merged 1 commit into from
Feb 10, 2022

Conversation

alexcrichton
Copy link
Member

This commit has a few minor updates and some improvements to the
instantiation benchmark harness:

  • A once_cell::unsync::Lazy type is now used to guard creation of
    modules/engines/etc. This enables running singular benchmarks to be
    much faster since the benchmark no longer compiles all other
    benchmarks that are filtered out. Unfortunately I couldn't find a way
    in criterion to test whether a BenchmarkId is filtered out or not so
    we rely on the runtime laziness to initialize on the first run for
    benchmarks that do so.

  • All files located in benches/instantiation are now loaded for
    benchmarking instead of a hardcoded list. This makes it a bit easier
    to throw files into the directory and have them benchmarked instead of
    having to recompile when working with new files.

  • Finally a module deserialization benchmark was added to measure the
    time it takes to deserialize a precompiled module from disk (inspired
    by discussion on Use mmap'd *.cwasm as a source for memory initialization images #3787)

While I was at it I also upped some limits to be able to instantiate
cfallin's spidermonkey.wasm.

This commit has a few minor updates and some improvements to the
instantiation benchmark harness:

* A `once_cell::unsync::Lazy` type is now used to guard creation of
  modules/engines/etc. This enables running singular benchmarks to be
  much faster since the benchmark no longer compiles all other
  benchmarks that are filtered out. Unfortunately I couldn't find a way
  in criterion to test whether a `BenchmarkId` is filtered out or not so
  we rely on the runtime laziness to initialize on the first run for
  benchmarks that do so.

* All files located in `benches/instantiation` are now loaded for
  benchmarking instead of a hardcoded list. This makes it a bit easier
  to throw files into the directory and have them benchmarked instead of
  having to recompile when working with new files.

* Finally a module deserialization benchmark was added to measure the
  time it takes to deserialize a precompiled module from disk (inspired
  by discussion on bytecodealliance#3787)

While I was at it I also upped some limits to be able to instantiate
cfallin's `spidermonkey.wasm`.
@alexcrichton alexcrichton merged commit 1cb08d4 into bytecodealliance:main Feb 10, 2022
@alexcrichton alexcrichton deleted the benchmark-tweaks branch February 10, 2022 21:40
mpardesh pushed a commit to avanhatt/wasmtime that referenced this pull request Mar 17, 2022
This commit has a few minor updates and some improvements to the
instantiation benchmark harness:

* A `once_cell::unsync::Lazy` type is now used to guard creation of
  modules/engines/etc. This enables running singular benchmarks to be
  much faster since the benchmark no longer compiles all other
  benchmarks that are filtered out. Unfortunately I couldn't find a way
  in criterion to test whether a `BenchmarkId` is filtered out or not so
  we rely on the runtime laziness to initialize on the first run for
  benchmarks that do so.

* All files located in `benches/instantiation` are now loaded for
  benchmarking instead of a hardcoded list. This makes it a bit easier
  to throw files into the directory and have them benchmarked instead of
  having to recompile when working with new files.

* Finally a module deserialization benchmark was added to measure the
  time it takes to deserialize a precompiled module from disk (inspired
  by discussion on bytecodealliance#3787)

While I was at it I also upped some limits to be able to instantiate
cfallin's `spidermonkey.wasm`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants