-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Performance #85
Comments
Wasmtime uses Cranelift, which we know doesn't yet have all the optimization features we're planning for it to have, and we know it's not competitive with browser wasm engines yet. That said, I also do recommend caution when interpreting microbenchmarks. |
This issue is not actionable. In addition a lot has changed since this issue was created, so it may already be fixed. |
We've had a number of significant performance improvements since this issue was filed (most notably: new backend, with new register allocator), and while we're still not quite as fast as V8 or SpiderMonkey, we're getting closer. We're hoping to have some continuous performance measurement infrastructure working soon (bytecodealliance/rfcs#3, bytecodealliance/rfcs#4) so we should prefer that for tracking over this general issue, I think. |
This adds a basic scaffolding for WASI HTTP proposal as defined [here](https://github.com/WebAssembly/wasi-http/tree/1185b0a0224bc3e11274ad6298fd065cae472651/wit).
…am-3 Merge upstream
I've tried several simple cpu bounded benchmarks. It seems that in general wasmtime is twice slower than V8 or Spider Monkey.
The text was updated successfully, but these errors were encountered: