I didn't realize this was a JSON requirement until I started reading the spec carefully, but this is a _very_ bad mistake.
-
Show this thread
-
The sad part is this could have been trivially fixed by just saying that the escape characters can all be escaped by \('a'+#) or something, and then it would have had an amplification factor of 2. But AFAICT, there is no way to escape many of the required codes with less than 6.
2 replies 0 retweets 18 likesShow this thread -
Replying to @cmuratori
Most have two character codes, but other than " and maybe newline it's rarepic.twitter.com/jQwFT1XXGV
1 reply 0 retweets 0 likes -
Replying to @beached_whale @cmuratori
unicodes in json are 6 string characters. '\u007F'. If you do it Casey's way, it's two '\'+chr(0x7F).
2 replies 0 retweets 0 likes -
Replying to @LyleJantzi @beached_whale
The problem is very simple. If you are handed a buffer and you need to know how much space the JSON encode will take, right now it's 6*size. If you fixed this, it would be 2*size. It is an important difference.
1 reply 0 retweets 3 likes -
Replying to @cmuratori @LyleJantzi
The strings being encoded, other than the ones in the image can be as is. utf8 with a codepoint >0x19 is all good
2 replies 0 retweets 0 likes -
Replying to @beached_whale @LyleJantzi
This doesn't affect the problem at all. The maximum size before parsing is still 6*size, and always will be, because until you inspect the contents of the input, you don't know whether it will contain, for example, entirely 0x01's.
3 replies 0 retweets 2 likes -
Replying to @cmuratori @LyleJantzi
It would be interesting to see if counting and doing a single allocation would be fastests. On the parsing side it has shown to be the case. Luckily the string can be treated as hex and then it becomes a single allocation with O(1) size lookup * 2
1 reply 0 retweets 0 likes -
Replying to @beached_whale @LyleJantzi
I have no idea what you're talking about. You cannot "treat" the string as anything in particular. You just have an input buffer of size n and you need to write the output into a JSON buffer, and that requires 6*n space in the worst case. Period. That is all there is to say?
1 reply 0 retweets 1 like -
Replying to @cmuratori @LyleJantzi
If both sides agree the string can be encoded as hex. This isn't uncommon for binary data as string in json. Doesnt work for dropbox though
1 reply 0 retweets 0 likes
If both sides agree you don't have to send JSON! How is that helping?
-
-
Replying to @cmuratori @LyleJantzi
Putting hex in a string is within the spec. Either way, yeah it’s bigger
1 reply 0 retweets 0 likes -
Replying to @beached_whale @LyleJantzi
BUT IF BOTH SIDES AGREE YOU DO NOT NEED TO SEND JSON. YOU WOULD JUST SEND THE STRING AS A RAW BINARY AND IT IS 1X THE SIZE. At the risk of stating the obvious, nobody who cares about these things would ever send JSON to each other. You'd use a more efficient encoding.
1 reply 0 retweets 3 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.