The feed_event() function is called for every wasm binary instruction.
Let's optimize it by storing FunctionEnvironment object in
CraneliftFunctionCodeGenerator, rather than constructing it for every
feed_event() invocation.
This change reduces the time to run "ngix compile" benchmark by 68%:
Before:
nginx compile time: [1.4152 s 1.4186 s 1.4222 s]
Found 1 outliers among 10 measurements (10.00%)
1 (10.00%) high mild
After:
nginx compile time: [447.76 ms 448.32 ms 448.80 ms]
change: [-68.542% -68.440% -68.352%] (p = 0.00 < 0.05)
Performance has improved.
I assume some of the clone() calls are very expensive (Vec::clone(),
likely). I did see libc malloc()/free() high up in "perf top" profiles,
which are eliminted by this change.
I also looked into eliminating FunctionBuilder construction from
feed_event(). That turns out to be painful on lifetime rules because it
borrows bunch of other objects, so I am leaving it for someone who knows
the code better than I do.
600: Remove all uses of mem::uninitialized for Rust 1.38 r=syrusakbary a=MarkMcCaskey
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Syrus Akbary <me@syrusakbary.com>
595: Add useful functions for external use of WASI filesystem r=MarkMcCaskey a=MarkMcCaskey
part of #583
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Mark McCaskey <markmccaskey@users.noreply.github.com>
594: Improvement cache in Windows r=syrusakbary a=syrusakbary
Caching was disabled on Windows, but can be re-enabled easily by improving the folder cache naming.
Reason why caching was disabled on Windows: We use a very long string (64 chars) for the wasmer version (hash). But we can use the version directly (no need to hashing)
Co-authored-by: Syrus Akbary <me@syrusakbary.com>
587: Use --enable-simd to control whether SIMD is enabled in the wasmparser. r=nlewycky a=nlewycky
Before this change, 'wasmer run --backend=llvm some-simd.wasm' would run without complaint.
Also, note that the flag is not part of the cache key, so after any successful run, we can run it again without passing the flag.
Co-authored-by: Nick Lewycky <nicholas@mxc.ca>
Co-authored-by: Nick Lewycky <nick@wasmer.io>
Co-authored-by: nlewycky <nick@wasmer.io>
Before this change, 'wasmer run --backend=llvm some-simd.wasm' would run without complaint.
Also, note that the flag is not part of the cache key, so after any successful run, we can run it again without passing the flag.
Building Wasmer is bit of a pain, because it requires Rust nightly, and
bunch of OS specific packages.
To make building easier, this adds a "build" script at the top-level
directory, which can be used to build Wasmer within a Docker sandbox
that has all the necessary dependencies installed. The build environment
is based on latest Ubuntu 19.04.
You first need to build a Docker image of the sandbox:
docker build --file Dockerfile.build --tag wasmer-build .
Then, to build Wasmer, run:
./build make
To test Wasmer, run:
./build make test
and so on.
You can also drop into a shell within the Docker with:
./build
The "build" script bind mounts current directory as "/wasmer" in the
Docker container, which allows inspecting the build contents like you
had built them on your local machine.
For future improvements, we should consider:
- Consolidation with existing Dockerfile (that is used for Circle CI)
- Publishing the build sandbox image on Docker Hub so that people
don't have to build it themselves
- Moving dependency installation to separate script, which can be
reused outside of the Docker sandbox.
The work has been inspired by "devtool" in the Firecracker project:
https://github.com/firecracker-microvm/firecracker/blob/master/tools/devtool
and "dbuild" in the Scylla project:
https://github.com/scylladb/scylla/blob/master/tools/toolchain/dbuild
