This is really situational, because JSON.parse is really fast. With small workloads you will measure it in tens of microseconds. But it does block the event loop.
Agreed, parse is a lot faster than storage, but definitely can take more than 16.7ms with significant packets. You'd be trading performance for a smooth out, sometimes worth it with large packets. Should only be used if there is a glitch present I'd say.
Yes, even though response.json() looks like it's async, it isn't. So parsing JSON is a lot faster than stringifying it, but if it was huge then this would help. Part of the reason for writing js-c was that I needed an async json.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Is there any performance benefit using
parseAsync(response.text())
than the usualresponse.json()
?This is really situational, because
JSON.parse
is really fast. With small workloads you will measure it in tens of microseconds. But it does block the event loop.Agreed, parse is a lot faster than storage, but definitely can take more than 16.7ms with significant packets. You'd be trading performance for a smooth out, sometimes worth it with large packets. Should only be used if there is a glitch present I'd say.
If it was an option, I'd also consider using
ndjson
to split up the JSON objects into manageable chunks to get the best of both worlds.Yes, even though response.json() looks like it's async, it isn't. So parsing JSON is a lot faster than stringifying it, but if it was huge then this would help. Part of the reason for writing js-c was that I needed an async json.