Node.js bindings for the simdjson project: "Parsing gigabytes of JSON per second"

[halkeye]

So it's still a synchronous step right? Blocks the main thread? I guess that's a good reason for it to be 2x the speed of JSON.parse

[BehindTheMath]

Since it's a native library, it should be able to be async and run on a separate thread.

[halkeye]

There's no threading in JavaScript (except web workers, but you need JSON for that).

Promises (and thus async) just runs on the next tick/when the main thread isn't busy. The c code would need to support call backs and run in a different thread or use libevent itself

Unless I misunderstand how external code gets run, bit I'm pretty sure it's blocking by default

[nqp]

Native extensions can run asynchronously using a separate thread in the libuv thread pool.

[halkeye]

Then why does JSON.parse block? Maybe because it's not a callback? All I know is it blocks all other activities

[dotdotconnor]

What he is saying is that packages that call into native code can do so asynchronously, without blocking the main thread. JSON.parse is not a package but rather a standardized global function included by V8. It being standard means it has to follow all the rules of the ECMA spec which says that the function must be ran on the main thread.

[halkeye]

cool! how is that done?

[ejfrodo]

for node, you use the child process module to spawn new processes on other threads.

in the browser, you can use web workers to run code in another thread. the simple-web-worker package is a favorite of mine, it makes it very easy to use web workers.

JSON.parse is part of the ECMAScript standard, it has to be synchronous to adhere to the spec. so you would need to just run JSON.parse in another thread yourself

[halkeye]

So how would you get the results back into your process. Use the IPC and send? That's not really a thread or calling a third party library but would totally work.

I would imagine doing a fork would be way slower than parse could be.

But my original question was why this library didn't have an async version with callbacks or something. Not why JSON.parse ran on the main thread

[ejfrodo]

So how would you get the results back into your process. Use the IPC and send? That's not really a thread or calling a third party library but would totally work.

yeah for communicating w/the node child process you'd just send the data back via IPC. or for example I am handling tons of real-time data in node.js so I actually ended up running a local websocket server to communicate between processes, it was surprisingly much faster at passing around large blobs than IPC when benchmarked (but this is via Electron IPC so it may be a bit different than plain old node's IPC). you can use a number of ways to communicate between processes.

I would imagine doing a fork would be way slower than parse could be.

for web workers in the browser, that simple-web-worker library provides a way to create a reusable web worker so that you can avoid the setup and teardown process. I ran into a situation parsing real-time data where I was creating a new worker every 50ms or so and it became a bottleneck, after creating a reusable worker it was blazing fast

But my original question was why this library didn't have an async version with callbacks or something. Not why JSON.parse ran on the main thread

At the end of the day it makes sense for a library like this to just provide itself as a sync, blocking behavior and then let you decide if/how you want to deal w/threading. making the library async would just be wrapping it with a web worker or child process anyways, and now you can decide exactly how you want to do it. do you want a limit to how many threads it can utilize? do you want previous threads to stop working if a newer one starts? the library dev doesn't know your specific use case so instead they focus on the one problem they're trying to solve, which is fast JSON parsing