Status compared to JSOX itself

[aminya]

What is the status of this compared to JSOX itself?

[d3x0r]

the overhead of exchanging the strings with the WASM and/or creating the JS objects back out was slower than just the JS version...
Edit:
the managed allocation parser IS faster itself; but, the cost of interfacting to the WASM heaps and back is incredibly high; each string that's discovered has to be convered from a array of bytes in a Uint8arry Heap into a JS string ( which internally is utf-16, where the heap is utf-8; but even if it was the same it wouldn't change the overhead very much)

[aminya]

That is unfortunate. This is a known issue. WebAssembly/interface-types#38. We can see if things change.

on that thread, a part of the issue seems to be UTF16 <-> UTF8 conversion. Could you adjust the WASM code to use UTF16? @d3x0r

There is another issue regarding this: WebAssembly/interface-types#13

Node seems to give the option for this string encoding. So we may get higher speed by running the code inside Node.
https://kevin.burke.dev/kevin/node-js-string-encoding/

[d3x0r]

well; the target is node; the overall size of the wasm module is larger than the JS also (especially if minimized and gzipped)
I recently removed all the dual-mode options to be able use wchar in place of char...
for this specific use it might not be a big change for just that module... and there are still support things for going between.... just previously every char like thing was optional wchar (which was ugly and painful to maintain since I didn't compile wide like ever ...
those are good threads to watch

[d3x0r]

This also is lacking the prototype revivals for 'class' support... because the early just JSON-esque tests were so very slow...
This is more of a proof of concept; for parsing I use several internal data structures, and really isn't as much code as the .cc would be here... it's just there's lots of little peices all scattered...
This is the parser - just fills a container strcture with struct jsox_value_container types
https://github.com/d3x0r/SACK/blob/master/src/netlib/html5.websocket/json/jsox_parser.c

There is a small bit of source in this wasm-jsox version to build some objects from those structs... the node addon has

https://github.com/d3x0r/sack.vfs/blob/master/src/jsoxParse.cc (node C++ interface)
https://github.com/d3x0r/sack.vfs/blob/master/sack-jsox.js (JS internal interface' (mostly just the stringifiier here, but handles allocating the maps and things to track class types, which the jsoxParse.cc module has.)

jsoxParse.cc is what really needed to be ported to emscripten C++ binding interface sort of thing :)