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

AssemblyScript WASM Build #23

Open
Offroaders123 opened this issue May 15, 2024 · 2 comments
Open

AssemblyScript WASM Build #23

Offroaders123 opened this issue May 15, 2024 · 2 comments

Comments

@Offroaders123
Copy link
Contributor

Would building a WASM binary from the same TypeScript code, by way of AssemblyScript, provide any noticeable performance gains I wonder? I haven't had any challenges with speed at all with how the library currently stands, but I wonder if it's something that could help for really large/lots of buffers to encode and decode? It would be more of an enhancement for the greater scheme of things, if it did have any noticeable changes.

I've been pondering this on my own, and I was curious if you may have already considered this before. It might not have any notable performance benefits over the plain JS implementation here, but I'm curious enough to look into it.

As a concept, a project like this seems to be one of the few examples where something like AssemblyScript could actually work great.

I think another reason to why I thought of this is because I thought I remember hearing at some point that the built-in Text Encoding APIs are backed by native code, and I wondered if moving to a JS-based approach would have any noticeable speed differences compared to the native one.

Thanks again for making this project! I think I'm looking to use it for my Minecraft NBT parsing library, NBTify.

Offroaders123/NBTify#42

@Offroaders123
Copy link
Contributor Author

I tried this out with my NBT parser, and from my tests at least, it seemed like this MUTF-8 implementation is just a hair behind the Text Encoding APIs themselves, but it did fluctuate in a few cases where this one was actually faster. That was just with the plain JS implementation here, I didn't get a WASM build setup yet. If anything, it's just down to the tenths or hundredths of a millisecond, so it's barely any different if anything. Overall it did take longer though, so I'm going to see if WASM does anything different as well. I kind of expect it to be slower than this plain setup, since it will have to do all of the initial setup to get the WASM space configured.

UTF-8

utf-8

MUTF-8

mutf-8

Offroaders123 added a commit to Offroaders123/mutf-8 that referenced this issue May 18, 2024
Things aren't working according to the tests, I'm going to stick with using the plain JS implementation itself. This was a learning-packed demo to set this up though! I borrowed aspects of this from my WASM-AS project. The AssemblyScript docs have a lot of nice information on how to set things up accordingly, and what is supported in either JS or WASM.

https://www.assemblyscript.org/status.html
https://www.assemblyscript.org/compiler.html

sciencesakura#23
@sciencesakura
Copy link
Owner

@Offroaders123

Thank you for your thoughtful suggestion and interest in this project!

I haven't yet considered the approach you present in detail, but your points about potential performance gains, especially when dealing with large messages, and the suitability of AssemblyScript for such a simple library make sense.

On the other hand, I believe that a simple library like this one can also benefit from the optimizations provided by the JS runtime. This could mean that the performance gains from switching to AssemblyScript might not be as significant as expected, but it's certainly worth investigating.

Thank you again. If you have any findings on this matter, I would love to hear them.

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

No branches or pull requests

2 participants