11–20 of 193 posts
[flagged]
Did you even open the article? Following is literally in first paragraph > This package offers the same high level json.Decoder API but higher throughput and reduced allocations
[flagged]
Exactly, it's not too hard to implement in C. The one I made never copied data, instead saved the pointer/length to the data. The user only had to Memory Map the file (or equivalent), pass that data into the parse. Only memory allocation was for the Jason nodes. This way they only paid the parsing tax (decoding doubles, etc..) if the user used that data. You hit the nail on the head
[flagged]
Exactly, it's not too hard to implement in C. The one I made never copied data, instead saved the pointer/length to the data. The user only had to Memory Map the file (or equivalent), pass that data into the parse. Only memory allocation was for the Jason nodes. This way they only paid the parsing tax (decoding doubles, etc..) if the user used that data. You hit the nail on the head
[flagged]
Exactly, it's not too hard to implement in C. The one I made never copied data, instead saved the pointer/length to the data. The user only had to Memory Map the file (or equivalent), pass that data into the parse. Only memory allocation was for the Jason nodes. This way they only paid the parsing tax (decoding doubles, etc..) if the user used that data. You hit the nail on the head
I’ve seen this referred to as a pull parser in a Rust library? (https://github.com/raphlinus/pulldown-cmark)
[flagged]
Absolute highest performance is rarely the highest priority in designing a system.
Of course we could design a hyper-optimized, application specific payload format and code the deserializer in assembly and the performance would be great, but it wouldn’t be useful outside of very specific circumstances.
In most real world projects, performance of Go and JSON is fine and allow for rapid development, easy implementation, and flexibility if anything changes.
I don’t think it’s valid to criticize someone for optimizing within their use case.
> I feel like it should deserve a mention of what the stack is, otherwise there is no reference point.
The article clearly mentions that this is a GopherCon talk in the header. It was posted on Dave Cheney’s website, a well-known Go figure.
It’s clearly in the context of Go web services, so I don’t understand your criticisms. The context is clear from the article.
The very first line of the article explains the context:
> This talk is a case study of designing an efficient Go package.
I don't know how "true" that comment is but I thought I should try to write a parser myself to get a feel :D
So I wrote one, in Python - https://arunmani.in/articles/silly-json-parser/
It was a delightful experience though, writing and testing to break your own code with different variety of inputs. :)
[flagged]
Exactly, it's not too hard to implement in C. The one I made never copied data, instead saved the pointer/length to the data. The user only had to Memory Map the file (or equivalent), pass that data into the parse. Only memory allocation was for the Jason nodes. This way they only paid the parsing tax (decoding doubles, etc..) if the user used that data. You hit the nail on the head
The first line of the article explains the context of the talk:
> This talk is a case study of designing an efficient Go package.
The target audience and context are clearly Go developers. Some of these comments are focusing too much on the headline without addressing the actual article.
I remember reading a SO question which asks for a C library to parse JSON. A comment was like - C developers won't use a library for JSON, they will write one themselves. I don't know how "true" that comment is but I thought I should try to write a parser myself to get a feel :D So I wrote one, in Python - https://arunmani.in/articles/silly-json-parser/ It was a delightful experience though, writing and testing to br…
[flagged]
Exactly, it's not too hard to implement in C. The one I made never copied data, instead saved the pointer/length to the data. The user only had to Memory Map the file (or equivalent), pass that data into the parse. Only memory allocation was for the Jason nodes. This way they only paid the parsing tax (decoding doubles, etc..) if the user used that data. You hit the nail on the head
Always nice to be in control over memory :)
The walkthrough is very nice, how to do this if you're going to do it. If you're going for pure performance in a production environment you might take a look at Daniel Lemire's work: https://github.com/simdjson/simdjson . Or the MinIO port of it to Go: https://github.com/minio/simdjson-go .
If your JSON always looks the same you can also do better than general JSON parsers.