iswasmfast
proposal-regexp-match-indices
Our great sponsors
iswasmfast | proposal-regexp-match-indices | |
---|---|---|
4 | 4 | |
190 | 58 | |
- | - | |
0.0 | 1.0 | |
over 1 year ago | almost 2 years ago | |
JavaScript | HTML | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
iswasmfast
-
Pay Attention to WebAssembly
At a glance, the bindings for wasm copy the data,
https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185...
If the running code is short enough then that copy might easily make the wasm version much slower. That is indeed a known downside of wasm (calls to JS are somewhat slow, and copying of data even more so - wasm shines when you can avoid those things).
If it's not that, then a 10x difference suggests you are running into some kind of a VM bug or limitation.
-
Node.js 16 Available Now
WASM has its moments, as you can see in this[1] benchmark it outperforms JS and native addons on certain tasks.
Since the bottleneck with native addons is usually data copying/marshalling, and we have direct access to WebAssembly memory from the JavaScript side, using WebAssembly on this "shared" memory might become the best approach for computationally heavy tasks. I wrote about it a bit here[2].
[1] https://github.com/zandaqo/iswasmfast
-
Is WebAssembly magic performance pixie dust?
A few years ago I did similar comparison but in context of Node.js and sans manual optimizations: https://github.com/zandaqo/iswasmfast
In my work, I have come to conclusion that it seldom pays off to go "native" when working with Node.js. More often than not, rewriting some computationally heavy code in C and sticking it as a native module yielded marginally better results when compared with properly optimized js code. Though, that doesn't negate other advantages of using said technologies: predictable performance from the start and re-using existing code base.
proposal-regexp-match-indices
-
Unveiling Breakthroughs Found In The State Of JS 2022 Survey
For more info about this feature, you can refer to the official proposal repo.
-
How JavaScript works: regular expressions (RegExp)
It should be mentioned that this feature isn't part of the ECMAScript specification yet. It's currently a stage 3 proposal and will likely be part of ES2021 or ES2022.
- Node.js 16 Available Now
-
ES 2021 features (all 5 of them)
RegExp Match Indices (?)
What are some alternatives?
neon - Rust bindings for writing safe and fast native Node.js modules.
public-roadmap - Checkly public roadmap. All planned features, updates and tweaks.
expresscpp - Fast, unopinionated, minimalist web framework for C++ Perfect for building REST APIs
proposal-relative-indexing-method - A TC39 proposal to add an .at() method to all the basic indexable classes (Array, String, TypedArray)
human-asmjs - Tips and tricks for writing asm.js as a human - Note: WebAssembly has replaced asm.js, so this is no longer maintained.
proposal-top-level-await - top-level `await` proposal for ECMAScript (stage 4)
friendly-pow - The PoW challenge library used by Friendly Captcha
proposal-nullish-coalescing - Nullish coalescing proposal x ?? y
proposals - Tracking WebAssembly proposals
proposal-weakrefs - WeakRefs
design - WebAssembly Design Documents
proposals - Tracking ECMAScript Proposals