5 ms·
Hmm, I'm starting to think my definition of "small" is different from everybody else's. I consider "smallish" JSON to be at most 100KB (and on average 1-10 KB).
by umvi 7y ago
Hmm, I'm starting to think my definition of "small" is different from everybody else's. I consider "smallish" JSON to be at most 100KB (and on average 1-10 KB). 1 MB I consider to be "large"... basically anything that doesn't parse near instantaneously I consider "large".
- Uehreka 7y agoI think GP might've been saying 1M small JSON documents, rather than a single document containing 1M strings.
- ken 7y agoIsn't that tautological? Clearly, no JSON parser provides a significant gain on parse speed of small JSON documents, when you define large as those where parse time is significant.
- umvi 7y agoWell, Python2 -> Python3 introduced a dramatic performance increase, even for small JSON documents.
- IanCal 7y agoThese were small though, I just made a small sample of a million of them and still saw a 2x improvement.
- coldtea 7y ago>Isn't that tautological? No, it's no. >Clearly, no JSON parser provides a significant gain on parse speed of small JSON documents, when you define large as those where parse time is significant. A rather bizarre deduction. E.g. "define large as those where parse time is significant". So let's say a large file is one whose parse time is > 10 seconds. So, while looking at small, ie. < 10 second parse time files, if a JSON parser takes files that others load in 500ms and load them in 20ms, then that's "a significant gain on parse speed of small JSON documents"... We didn't have to change any of the definitions...
- nicoburns 7y agoIf you use a language like Rust (which is really easy for these kind of jobs), then 1mb will parse almost instantly. I've been working with a 90gb JSON file recently. I'd probably start counting a file as large at around 100mb.
- aisengard 7y agoI have to ask - why? I understand if you're dealing with an external resource that you can't change, but I'd still like to ask them the same question. JSON's strength, it seems to me, is that it's great for human consumption. It's a very readable data structure when serialized! But who is ever going to read 90GB of JSON?
- nly 7y agoNot OP, but I deal with a variety of proprietary binary/encoded files in the 10s of MB to the 10s of GB range at work, and we have started decoding to JSON as the first step in our normalization, indexing and analytics pipeline (To be honest we essentially just throw everything in to MongoDB). Daily we're in the terabyte range. It's the perfect solution because you can use the same decoder + something like jq for debugging and manipulation on the command line.
- e12e 7y agoA question - do know of any good resources for jq? I haven't quite been "angry enough" to use jq much beyond using it for formatting json - but that's also partly because I can't seem to quite grasp the syntax. It isn't quite "awk-ish", not quite cut/join/sort/uniq. But also not quite graphql? Which I suppose would be the "natural" language for a json-query tool? I feel like I'm missing a piece - and missing out...
- chucky_z 7y agoThe manual is pretty dang good, tbh. https://stedolan.github.io/jq/manual/ https://stedolan.github.io/jq/manual/
- IanCal 7y agoOh I think you misunderstood, they are all small, there's just a million of them. I think they were all about 1k.