Please help with writing spec for async JSON APIs

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Please help with writing spec for async JSON APIs

Mohsen Azimi
Hi,

I stumbled on lack of async APIs for JSON parsing and stringifying in JavaScript a couple of weeks ago. I tried to hack around it by abusing the W3C Fetch API but that's just a hack.

Domenic suggested that we should write the proposal spec for native non-blocking JSON processing. I don't know what the API should look like but I made some assumptions and wrote the initial spec (if I can call it spec!) and published it in GitHub.

I need to learn the spec lingo and rewrite the spec in proper and standard language. I need help and resources to learn the language of the spec.

Would you please review the proposal so far (including the outstanding PR)?

Thanks,
Mohsen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Kevin Smith
Hi Moshen,

The semantics of your proposal are straightforward, so I don't think you need to provide spec text at this point.  Instead, what would be helpful is a quantitative analysis showing why these additional methods are needed.  Is there any way you can demonstrate the benefit with numbers?


On Fri, Jul 31, 2015 at 11:04 PM Mohsen Azimi <[hidden email]> wrote:
Hi,

I stumbled on lack of async APIs for JSON parsing and stringifying in JavaScript a couple of weeks ago. I tried to hack around it by abusing the W3C Fetch API but that's just a hack.

Domenic suggested that we should write the proposal spec for native non-blocking JSON processing. I don't know what the API should look like but I made some assumptions and wrote the initial spec (if I can call it spec!) and published it in GitHub.

I need to learn the spec lingo and rewrite the spec in proper and standard language. I need help and resources to learn the language of the spec.

Would you please review the proposal so far (including the outstanding PR)?

Thanks,
Mohsen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
joe
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

joe
JSON parsing is such a slow process that it motivated me to re-invent Google Protobufs (in a nice, JS-friendly way, see https://github.com/joeedh/STRUCT/wiki/Intro-and-Examples ).  I never use JSON in production code for this reason.  An async api isn't a bad idea.

Joe

On Fri, Jul 31, 2015 at 8:32 PM, Kevin Smith <[hidden email]> wrote:
Hi Moshen,

The semantics of your proposal are straightforward, so I don't think you need to provide spec text at this point.  Instead, what would be helpful is a quantitative analysis showing why these additional methods are needed.  Is there any way you can demonstrate the benefit with numbers?


On Fri, Jul 31, 2015 at 11:04 PM Mohsen Azimi <[hidden email]> wrote:
Hi,

I stumbled on lack of async APIs for JSON parsing and stringifying in JavaScript a couple of weeks ago. I tried to hack around it by abusing the W3C Fetch API but that's just a hack.

Domenic suggested that we should write the proposal spec for native non-blocking JSON processing. I don't know what the API should look like but I made some assumptions and wrote the initial spec (if I can call it spec!) and published it in GitHub.

I need to learn the spec lingo and rewrite the spec in proper and standard language. I need help and resources to learn the language of the spec.

Would you please review the proposal so far (including the outstanding PR)?

Thanks,
Mohsen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Forbes Lindesay
In reply to this post by Mohsen Azimi
You probably don’t want to support reviver/replacer in the async methods as they would be very challenging to make performant.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Morningstar, Chip
In reply to this post by Mohsen Azimi
I confess I don't see the point of this proposal at all, at least with respect to being specifically about JSON.

JSON parsing/stringification is pure computation; it's not like I/O where you need something special inside the language runtime's implementation in order to exploit the asynchrony.

While it would be generally useful to be able to hand a random chunk of CPU-bound work off to another thread on another processor core, there's no point whatsoever in treating JSON as a special case of this.  JSON handling is just one use case for asynchronous computation in general.  Presumably once the language's async features are fully baked you should be able to just wrap a call to the existing JSON API inside an async function, and get this functionality (and much else besides) directly.

Chip


On Jul 31, 2015, at 8:03 PM, Mohsen Azimi <[hidden email]> wrote:

Hi,

I stumbled on lack of async APIs for JSON parsing and stringifying in JavaScript a couple of weeks ago. I tried to hack around it by abusing the W3C Fetch API but that's just a hack.

Domenic suggested that we should write the proposal spec for native non-blocking JSON processing. I don't know what the API should look like but I made some assumptions and wrote the initial spec (if I can call it spec!) and published it in GitHub.

I need to learn the spec lingo and rewrite the spec in proper and standard language. I need help and resources to learn the language of the spec.

Would you please review the proposal so far (including the outstanding PR)?

Thanks,
Mohsen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Forbes Lindesay
I agree that we should probably look for a more general solution.  What we have at the moment is woefully inadequate though (I.e. WebWorkers on the client and separate processes in node.js

What we need some way of doing multi-threading baked into the language, but that could take a long time to properly standardise.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
joe
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

joe
In reply to this post by Morningstar, Chip
If we're speaking normatively, some of us don't see the point of using unstructured object serialization for web communication at all (it's not simply a binary-versus-text thing; I once implemented JSON's object model in a binary format, and it had the same speed as the native JSON parser).  That said, JSON *is* a standard, and it'd be nice if I could support it in more use cases (instead of telling cilents "can't do that, too slow").

If we must have JSON, let's at least make it minimally usable.  If that's too much to ask, than perhaps it's time browsers supported ProtoBufs/STRUCT type systems natively.

Joe


On Sat, Aug 1, 2015 at 11:35 PM, Morningstar, Chip <[hidden email]> wrote:
I confess I don't see the point of this proposal at all, at least with respect to being specifically about JSON.

JSON parsing/stringification is pure computation; it's not like I/O where you need something special inside the language runtime's implementation in order to exploit the asynchrony.

While it would be generally useful to be able to hand a random chunk of CPU-bound work off to another thread on another processor core, there's no point whatsoever in treating JSON as a special case of this.  JSON handling is just one use case for asynchronous computation in general.  Presumably once the language's async features are fully baked you should be able to just wrap a call to the existing JSON API inside an async function, and get this functionality (and much else besides) directly.

Chip


On Jul 31, 2015, at 8:03 PM, Mohsen Azimi <[hidden email]> wrote:

Hi,

I stumbled on lack of async APIs for JSON parsing and stringifying in JavaScript a couple of weeks ago. I tried to hack around it by abusing the W3C Fetch API but that's just a hack.

Domenic suggested that we should write the proposal spec for native non-blocking JSON processing. I don't know what the API should look like but I made some assumptions and wrote the initial spec (if I can call it spec!) and published it in GitHub.

I need to learn the spec lingo and rewrite the spec in proper and standard language. I need help and resources to learn the language of the spec.

Would you please review the proposal so far (including the outstanding PR)?

Thanks,
Mohsen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Michał Wadas
In reply to this post by Kevin Smith

Synchronous JSON parsing can block Node.js application. See following test case -  Chromium native parser can handle up to 44MB per second on my hardware. http://jsperf.com/json-parse-vs-1mb-json (BTW - I'm quite impressed by V8 garbage collector). http://jsperf.com/json-parse-vs-1mb-json

It's enough to perform easy DoS on reasonably configured low-end server.

Anyway - I don't think that asynchronous parsing/stringifing would solve this problem (it can solve some perfomance issues in WebSockets-based games preventing frame-drop).




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Bruno Jouhier
In reply to this post by Mohsen Azimi
A common use case is large JSON feeds: header + lots of entries + trailer

When processing such feeds, you should not bring the whole JSON in memory all at once. Instead you should process the feed incrementally.

So, IMO, an alternate API should not be just asynchronous, it should also be incremental.

FWIW, I have implemented an incremental/evented parser for V8 with a simple API. This parser is incremental but not async (because V8 imposes that materialization happen in the main JS thread). But, if the V8 restriction could be lifted, it could be made async with the same API. See https://github.com/bjouhier/i-json

i-json's API is a simple low level API. A more sophisticated solution would be a duplex stream.

There was also a long discussion on this topic on node's GitHub: https://github.com/joyent/node/issues/7543

Bruno

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Brendan Eich-2
Exactly! Incremental and async, i.e., streaming.

XML quickly needed such APIs
(https://en.wikipedia.org/wiki/Simple_API_for_XML,
https://en.wikipedia.org/wiki/StAX). JSON's in the same boat.

/be

Bruno Jouhier wrote:

> A common use case is large JSON feeds: header + lots of entries + trailer
>
> When processing such feeds, you should not bring the whole JSON in
> memory all at once. Instead you should process the feed incrementally.
>
> So, IMO, an alternate API should not be just asynchronous, it should
> also be incremental.
>
> FWIW, I have implemented an incremental/evented parser for V8 with a
> simple API. This parser is incremental but not async (because V8
> imposes that materialization happen in the main JS thread). But, if
> the V8 restriction could be lifted, it could be made async with the
> same API. See https://github.com/bjouhier/i-json
>
> i-json's API is a simple low level API. A more sophisticated solution
> would be a duplex stream.
>
> There was also a long discussion on this topic on node's GitHub:
> https://github.com/joyent/node/issues/7543
>
> Bruno
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Alexander Jones
Personally I just use small JSON records delimited by newlines in my 'streaming' applications. Best of both worlds IMO.

On Monday, 3 August 2015, Brendan Eich <[hidden email]> wrote:
Exactly! Incremental and async, i.e., streaming.

XML quickly needed such APIs (https://en.wikipedia.org/wiki/Simple_API_for_XML, https://en.wikipedia.org/wiki/StAX). JSON's in the same boat.

/be

Bruno Jouhier wrote:
A common use case is large JSON feeds: header + lots of entries + trailer

When processing such feeds, you should not bring the whole JSON in memory all at once. Instead you should process the feed incrementally.

So, IMO, an alternate API should not be just asynchronous, it should also be incremental.

FWIW, I have implemented an incremental/evented parser for V8 with a simple API. This parser is incremental but not async (because V8 imposes that materialization happen in the main JS thread). But, if the V8 restriction could be lifted, it could be made async with the same API. See https://github.com/bjouhier/i-json

i-json's API is a simple low level API. A more sophisticated solution would be a duplex stream.

There was also a long discussion on this topic on node's GitHub: https://github.com/joyent/node/issues/7543

Bruno
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Bruno Jouhier
In reply to this post by Mohsen Azimi
The SAX approach is not ideal for JSON because we don't want the overhead of a callback on every key (especially if parsing and callbacks are handled by different threads).

To be efficient we need is a hybrid approach with an evented API (SAX-like) for top level keys, and direct mapping to JS for deeper keys. In the feed case, you only need one event for the header, one for every entry and one for the trailer. In the i-json API I'm handling this with a `maxDepth` option in the parser constructor. 

Bruno 

2015-08-03 3:25 GMT+02:00 Brendan Eich <[hidden email]>:
Exactly! Incremental and async, i.e., streaming.

XML quickly needed such APIs (https://en.wikipedia.org/wiki/Simple_API_for_XML, https://en.wikipedia.org/wiki/StAX). JSON's in the same boat.

/be

Bruno Jouhier wrote:
A common use case is large JSON feeds: header + lots of entries + trailer

When processing such feeds, you should not bring the whole JSON in memory all at once. Instead you should process the feed incrementally.

So, IMO, an alternate API should not be just asynchronous, it should also be incremental.

FWIW, I have implemented an incremental/evented parser for V8 with a simple API. This parser is incremental but not async (because V8 imposes that materialization happen in the main JS thread). But, if the V8 restriction could be lifted, it could be made async with the same API. See https://github.com/bjouhier/i-json

i-json's API is a simple low level API. A more sophisticated solution would be a duplex stream.

There was also a long discussion on this topic on node's GitHub: https://github.com/joyent/node/issues/7543

Bruno
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Allen Wirfs-Brock
In reply to this post by Mohsen Azimi
So,  to summarize some things that have been said or are implicit in this thread and related discussions:

1) New JSON APIs could be added to JS. We don’t have to be limited to JSON.parse/stringify

2) We don’t have to be restricted to the JSON.stringify/parse mapping of JS objects from/to JSON texts

3) Streaming is a better processing model for some applications

4) JSON.parse/stringify are pure computational  operations.  There is no perf benefit to making them asynchronous unless some of their computation can be performed concurrently.

5) You can't just run JSON.parse (or stringify) concurrently with other JS “jobs” because of possible races

6) You could concurrently run the parsing phase of JSON.parse (steps 3-5 of http://ecma-international.org/ecma-262/6.0/#sec-json.parse ). 

7) You can not run the step 8 substeps (reviver processing) concurrently because they may call back into JS code and hence could introduce races.

8) Making JSON.stringify concurrent probably requires first copying/transferring the input object graph, but that is essentially the computation that JSON.stringify performs so it is hard to see any benefit. 



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Boris Zbarsky
On 8/3/15 11:34 AM, Allen Wirfs-Brock wrote:
> 4) JSON.parse/stringify are pure computational  operations.  There is no
> perf benefit to making them asynchronous unless some of their
> computation can be performed concurrently.

Or even just incrementally, right?

In practice, 500 chunks of 5ms of processing may be better for a GUI
application that wants to remain responsive than a single chunk of
2500ms, even if it doesn't happen concurrently, as long as it yields to
processing of user events.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Allen Wirfs-Brock

On Aug 3, 2015, at 8:45 AM, Boris Zbarsky wrote:

> On 8/3/15 11:34 AM, Allen Wirfs-Brock wrote:
>> 4) JSON.parse/stringify are pure computational  operations.  There is no
>> perf benefit to making them asynchronous unless some of their
>> computation can be performed concurrently.
>
> Or even just incrementally, right?
>
> In practice, 500 chunks of 5ms of processing may be better for a GUI application that wants to remain responsive than a single chunk of 2500ms, even if it doesn't happen concurrently, as long as it yields to processing of user events.
>
> -Boris

sure, but that's a user interactiveness benefit, not a "perf benefit".  There is almost always some overhead introduced when making a computation incremental. Responsiveness is a fine reason to make such a trade-off.

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Boris Zbarsky
On 8/3/15 11:56 AM, Allen Wirfs-Brock wrote:
> sure, but that's a user interactiveness benefit, not a "perf benefit".

OK, fair.  I just wanted it to be clear that there is a benefit to
incremental/asynchronous behavior here apart from raw throughput.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

James M Snell
In reply to this post by Allen Wirfs-Brock
On Mon, Aug 3, 2015 at 8:34 AM, Allen Wirfs-Brock <[hidden email]> wrote:
[snip]
>
> 4) JSON.parse/stringify are pure computational  operations.  There is no
> perf benefit to making them asynchronous unless some of their computation
> can be performed concurrently.
>

If we're speaking strictly about making the JSON parsing asynchronous,
then correct, there is really no performance benefit to speak of. You
may be able to offload the parsing to a separate thread, but it's
going to take the same amount of time. The real benefit will come when
(a) JSON parsing becomes incremental and (b) a developer is given
greater control over exactly how the JSON is converted to/from
strings.

Something along the lines of...

JSON.parser(input).
  on('key', function(key, context) {
    if (key === 'foo')
      console.log(context.value());
    else if (key === 'bar')
      context.on('key', ...);
  }).
  on('end', function() {
  });

In other words: allowing for incremental access to the stream and fine
grained control over the parsing process, rather than having to block
while everything is parsed out, building up the in-memory object
model, then being forced to walk that model in order to do anything
interesting.

Personally, I'm not overly concerned about the possibility of races.

- James
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Allen Wirfs-Brock

On Aug 3, 2015, at 9:02 AM, James M Snell wrote:

> On Mon, Aug 3, 2015 at 8:34 AM, Allen Wirfs-Brock <[hidden email]> wrote:
> [snip]
>>
>> 4) JSON.parse/stringify are pure computational  operations.  There is no
>> perf benefit to making them asynchronous unless some of their computation
>> can be performed concurrently.
>>
>
> If we're speaking strictly about making the JSON parsing asynchronous,
> then correct, there is really no performance benefit to speak of. You
> may be able to offload the parsing to a separate thread, but it's
> going to take the same amount of time. The real benefit will come when
> (a) JSON parsing becomes incremental

yes, incremental is good.  But do you really mean just "parsing" rather than "processing"?

> and (b) a developer is given
> greater control over exactly how the JSON is converted to/from
> strings.

Strictly speaking JSON is strings.  JSON.stringify/parse converts JS values (including objects) to/from such strings.

>
> Something along the lines of...
>
> JSON.parser(input).
>  on('key', function(key, context) {
>    if (key === 'foo')
>      console.log(context.value());
>    else if (key === 'bar')
>      context.on('key', ...);
>  }).
>  on('end', function() {
>  });
>

I have to guess at your semantics, but what you are trying to express above seems like something that can already be accomplished using the `reviver` argument to JSON.parse.

> In other words: allowing for incremental access to the stream and fine
> grained control over the parsing process, rather than having to block
> while everything is parsed out, building up the in-memory object
> model, then being forced to walk that model in order to do anything
> interesting.
>
> Personally, I'm not overly concerned about the possibility of races.

But, TC39 is concerned about races.

>
> - James
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

James M Snell
On Mon, Aug 3, 2015 at 10:29 AM, Allen Wirfs-Brock
<[hidden email]> wrote:
[snip]
>
> I have to guess at your semantics, but what you are trying to express above seems like something that can already be accomplished using the `reviver` argument to JSON.parse.
>

Yes and no. `reviver` achieves part of goal but but still assumes that
parsing is fundamentally blocking and assumes that I want to return
something and have that in-memory obj built up and returned. However,
if what I want instead is to forgo the creation of an in memory model
altogether and working simply from an incremental, async stream of
events, then I'm out of luck.

>> In other words: allowing for incremental access to the stream and fine
>> grained control over the parsing process, rather than having to block
>> while everything is parsed out, building up the in-memory object
>> model, then being forced to walk that model in order to do anything
>> interesting.
>>
>> Personally, I'm not overly concerned about the possibility of races.
>
> But, TC39 is concerned about races.
>

Granted ;-) ... there's a reason I prefixed that sentence with 'Personally' ;-)

>>
>> - James
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Please help with writing spec for async JSON APIs

Bruno Jouhier
In reply to this post by Mohsen Azimi
Reviver is a bit of a killer feature for async parsing because it imposes a callback on every key. It makes it difficult to efficiently offload parsing to a worker thread. Without it, feed entries could be parsed and materialized safely (provided GC allows it) in a separate thread and then emitted to the main JS thread.

In our "big JSON feeds" scenarios we never use revivers, and actually I'm not sure we even use them on small JSON payloads.

Is this feature really necessary in an async/incremental API variant?



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12