8e0651374a
Investigating a susprisingly slow-compiling module recently, it turns out that if you create a wasm module with 40k empty functions (e.g. `(module (func) (func) (func) ...)`) then it takes **3 seconds** to compile and drop via the CLI locally on a Linux system. This seems like an extraordinary amount of time for "doing nothing", and after some profiling I found that basically all of the time was spent in `__deregister_frame` calls. Poking around in the source it looks like libgcc is managing some form of linked list, and by deregistering in the LIFO order instead of FIFO order it avoids a quadratic search of all registered functions. Now that being said it's still pretty bad to do a linear search all the time, and nothing will be fixed if there are *two* instances both with 40k functions. For now though I hope that this will patch over the performance issue and we can figure out better ways to manage this in the future.
This is the wasmtime-jit crate, which contains JIT-based execution
for wasm, using the wasm ABI defined by wasmtime-environ and the
runtime support provided by wasmtime-runtime.