You can take as much time as you need. We need to reach an agreement.
The payload encoding for JSON.parseBinary is utf8, as specificed in RFC8259.
Example you used is not quite what parseBinary does. It does not transform JS string into buffer, but Buffer into JS structures
var result = JSON.parseBinary(arrayBuffer)
if (result.ok) handlePayload(result.value)
else handleError(result.message)
There is no TextDecoder and no try-catch.
It can also accept Uint8Array and SharedArrayBuffer by design
OK, good, so there's no zero copy strings, that's what I thought. Why are you trying to hold me to that standard then if that standard is actually impossible?
Every problem you accused me of having you also have.
As I have already mentioned, it is not expected to do zero-copy handling, which is impossible. Now that you understood what I implied, I remind you that my target is to avoid TextDecoder and SyntaxError. By this I reduce memory usage, improve performance and failure path.
This proposal is not going to perform crazy stuff. And I did not accuse you, I accuse JS peculiarity. Neither implementation can make true zero-copy code in js
The zero-copy I'm describing is specifically this: a JSON string value like "ok" would, in the ideal case, be a JS String object containing only an offset and length into the existing binary payload - no bytes copied at all.
I'm just trying to read your message from the start. You started off saying this, which I now understand you to be saying you know are aware is impossible. If you know it's impossible, why lead with this?
You go on to say something else which isn't logical. You say:
On the code itself: the decode(bytes) call at the top holds a reference to bytes for the entire duration of parsing.
Yes, bytes is an iterator in my code, not a buffer like it is in yours. If it was a buffer it would be preventing old data from being garbage collected, but it is an iterator.
streamParseJSON(‘[“ok”]’) looks like “bytes” is a string.
And that zero-copy thing, let’s just pretend that we both went out of point. At least we resolved it.
Well you can't have looked at the code very hard at all then can you have! Yes the argument can be a string because a string is iterable.
The second example shows an actual async chunk-based file stream being passed as input to the same function: to this function, they're both just stream iterables, which is why there's only one code path and it handles both use cases.
When the input is really just a string there's obviously not any way to drop memory before the parse is done, but when the input is a chunk stream coming from the filesystem the key advantage the streamParseJSON has is that it NEVER holds a direct reference to any of the chunks. Therefore, after all the bytes in a chunk have been fed to the iterator, that chunk no longer has any live references and will be fed to the GC
1 Like
Alright. Now, what were we arguing about? Haha. If you have some questions - I am all ears
We shouldn't be arguing about anything! This is an absolute best-case outcome for you. You can have everything you want, and you can have it today.
1 Like
Under “today” what do you actually mean? I still got no one carrying my proposals to the committee. 
. So yeah, I’ll wait for this to happen.
I didn't finish writing my polyfill code, but it will have all the perf characteristics you want and it doesn't require any committee approval. It's just plain JS code. It runs fine today.
So if your code outperforms JSON.parse + TextDecoder, then COOL. But first step is a benchmark.
However ArrayBuffer.prototype.detach also has to be proposed. Polyfill exists, but does too much (buffer.transfer(0)).
Well I'm gonna have to build it for you to be able to run the speed test aren't I...
I wasn't planning to spend my time on this today, but arguing with you is more work than just writing the code. Here's what I've got so far: JSON stream parser for guthib-of-dan · GitHub
1 Like
Thanks in advance. If it does work faster, then I have no complaints. But just to clarify: are you sure that this implementation will beat potential JSON.parseBinary or current JSON.parse + TextDecoder in performance and memory? Or I again misunderstood something and the purpose of this code is different?
Yes, I'm absolutely sure that you will be able to construct a test where this code floors JSON.parse in terms of memory usage. What the raw perf is, that we will just have to see.
1 Like
I'd like to get back to my normally scheduled work for today.
Right now I haven't written the code to parser numbers and I haven't actually tried running this. Most of it is there, though.
Do you think you could run with it for a bit? I think we need to know if this solution works. If it doesn't, then I'm open to discussing other solutions.
(just fixed one more bug)
Now it's actually tested on basic inputs! Had to fix a lot more bugs. Again the gist is: JSON stream parser for guthib-of-dan · GitHub
The author confirmed that this was AI slop. That's why it lacked internally consistent logic.
Using AI for making shortcuts is not bad, until you understand what you do. Ideas are mine. Some formatting may come from AI. It is not required for me to do everything myself 24/7, if I have to complete many other projects. And “AI slop” is not appropriate name for this.
Thanks for effort, but I saw your “interest” in this when you wrote an example
JSON.parseBinary(‘“ok”’)
Were you to read the GitHub, you would never assume this kind of functionality.
How quickly this conversation turned into personal hate, didn’t it? These ideas are still relevant, MY creations and are not supposed to be banned just for me using some side help.
So yeah, if anyone has read the docs and has questions - ask and I will try my best to form an answer. If you are the delegate, willing to at least present this at a technical committee, you can reach out to me either here, or to my email (link in bio)
I assure you that it is not anything personal.
You claim you should be allowed to use it as long as it doesn't impede your performance. Fine. I'm saying you need to communicate better. You can't just paste 8 pages of text and expect me to sort it out on my time. Not when I know you didn't even take the time to write it