12 ms·
Sonic: A fast JSON serializing and deserializing library
- susodapop 5y agoReleased by ByteDance, who operate Tiktok.
- vmception 5y agoWhich probably means its solving a real world and modern problem they encounter and carries the same weight as a library released by Google
- unspecified 5y agoSmall (400B, 11 keys, 3 layers) Medium (13KB, 300+ key, 6 layers) Large (635KB, 10000+ key, 6 layers) I would be so happy to work somewhere where a 0.000635 GB json file is "large".
- hiyer 5y agoFrom the documentation it seems to me that they're mostly concerned about resource utilization when processing APIs, and not dealing with files. 635KB may be representative of a large API payload in their environment.
- throwaway889900 5y agoSeems like it's similar in performance to Jackson?
- uncomputation 5y agoSince when is 635 KB “large”? I suppose it depends on your use case, since they consider 400 B a small, they probably use lots of JSON APIs for many small things.
- otabdeveloper4 5y ago635kb is indeed "large" if it's one message. (You will have millions of messages in one file if you're doing batch processing.)
- BeeOnRope 5y agoJust another case where a library tests and publishes results for all competing libraries slower than it, but none faster. cough simdjson [1] cough --- [1] https://github.com/simdjson/simdjson https://github.com/simdjson/simdjson
- deleted 5y ago[deleted]
- nemothekid 5y agosimdjson is listed thought.
- memco 5y agoIt is mentioned here: https://github.com/bytedance/sonic/blob/a577eafc253adb943924f74f310509c6c80bd3f3/INTRODUCTION.md#research https://github.com/bytedance/sonic/blob/a577eafc253adb943924..., but it isn't included in the benchmarks graphs. Seems this repo is specifically focused on Golang and isn't necessarily motivated by being the fastest JSON [de]serializer on the planet.
- craigching 5y agoThere is this one though: https://github.com/minio/simdjson-go https://github.com/minio/simdjson-go EDIT: Apologies, simdjson-go is included in the benchmarks and discussed as well.
- BeeOnRope 5y agoWell it wasn't in the benchmark graphs and it didn't show in Ctrl+F in the README. Admittedly, I didn't do an exhaustive search.
- TkTech 5y agoA port of simdjson, simdjson-go, is in the benchmark graphs. It seems to be too fast to be visible in most of the graphs.
- TheMagicHorsey 5y agoIt seems its mostly written in assembly? I'd be worried about portability, maintainability, and security. I'd be way more comfortable if it was written in C, or better yet Rust.
- scottlamb 5y agoIt sounds like it essentially is written in C. INTRODUCTION.md says: > As for insufficiency in compiling optimization of go language, we decided to use C/Clang to write and compile core computational functions, and developed a set of asm2asm tools to translate the fully optimized x86 assembly into plan9 and finally load it into Golang runtime. Github says it's 59.6% assembly and 6.5% C. Possibly the assembly is just the checked-in result of compiling+translating the C? Gross that they have to do this. I know the Go folks really prioritize speed of compilation, but I wish they'd support debug builds with their own backend and release builds with LLVM so you could get this kind of performance when actually writing Go. I see there have been a few attempts at Go + general-purpose backend (gccgo, llgo, gollvm) but none seem to use the official Go frontend written in Go, so I think they're doomed to be second-class at best. edit: and/or, if the Go folks and GCC and/or LLVM coulds could negotiate a shared ABI (not necessarily switching to the platform's default C ABI but having "cc --abi=special-golang-stack-copying-thing"), folks could just link against something compiled in C/Rust/whatever without requiring this separate compilation+translation step (the high-maintenance, high-performance path) or CGo overhead (the easy but slow-for-frequent-calls path).
- latchkey 5y agoI really don't care what language it is written in. As long as there is full test coverage, I'm happy. I've been a long time user of jsoniter and it is much faster than the standard lib. It really makes a difference for the work I do. If this is even faster and has tests, even better.
- mastax 5y agoUsing Go assembly lets you avoid the Cgo overhead IIRC.
- leftnode 5y agoI regularly deal with JSON documents several MB in size, but do developers frequently deal with JSON documents several GB in size? If so, where do you encounter something like that? Surely "processing" that much data (for whatever definition of process you have) is orders of magnitude slower than parsing it. I love the idea of a library trying to squeeze every last bit of performance out of the CPU, but I'm genuinely curious at the problems it solves in the real world.
- Groxx 5y agoDepends. I've had multi-gigabyte `[{..}, {..}, ...]` json arrays from database dumps, and doing even basic things with that with jq takes ages unless you use the (highly obtuse IMO) streaming methods. Sometimes you can pre-grep to filter the results to something trivial to process, but sometimes the structure is not unique enough to let you do that, or it depends on multiple field values - filtering that with a json parser makes perfect sense, and then speed can matter. That said, a 2x+ improvement for a couple megabytes, especially if done many times per second, is still a significant improvement.
- nerdponx 5y agoHuge log files are one use case. Large datasets are another, in data analysis, machine learning, and ETL tasks.
- mayama 5y agoAren't log files processed a line at a time? Last time I had to deal with some structured log, I streamed lines concurrently into json parser and it went pretty fast.
- jeffbee 5y agoGeoJSON data can be just as big as you’d like. I have a big archive of GIS data where the files are enormous.
- thechao 5y agoHardware config file for a small SOC. It faithfully describes every addressable physical byte.
- greatgib 5y agoHow many libs we have seen saying that they are the fastest deserializing library, until you try to open files with corner cases, like ut8 characters...
- asadlionpk 5y agoI had to try working with a 100GB single json file. Couldn’t find anything that could work with that sized file.
- onion2k 5y agoAt that point you might as well ignore the fact it's JSON and just treat it as a stream.
- iainmerrick 5y agoOut of curiosity, what does "working with" mean here? What operations did you need to perform on it? Streaming reads, transforms, indexed reads, appends, edits? I'm thinking that any general-purpose JSON loader is likely to perform badly for a 100GB file, purely because it'll use 2x (or more likely 10x) as much memory for the parsed representation. So you'd want some kind of special-case reader for huge files -- maybe it just builds some kind of sparse index with pointers back into an mmap of the raw data.
- ZephyrBlu 5y agoWhy does it feel like there are consistently new JSON parsing libraries popping up? People joke about JS frameworks, but JSON parsers almost feel like they're at the same level.
- harrygeez 5y agosomehow when I saw it's a fast JSON serializing salary library I knew it's for Go. For some reasons there're always new JSON libraries for it
- rizzaxc 5y agoGo is kinda first class for microservice web app (and probably its only strong point)
- snailysnooze 5y agoweb development -> REST -> JSON -> JSON parsing libraries So like js frameworks, json parsers are everywhere
- bugmen0t 5y agoCool. What’s the interop story between Go‘s existing implementation for parsing objects with duplicate keys? Keep first, overwrite or abort?
- todotask 5y agoDoes it escape data by default? It appear to be a low-priority for the author in the issues.