sonnet
json
sonnet | json | |
---|---|---|
6 | 3 | |
281 | 325 | |
- | - | |
5.7 | 7.4 | |
7 months ago | 13 days ago | |
Go | Go | |
BSD 3-clause "New" or "Revised" License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sonnet
-
The latest JSON encode/decode benchmarks and analysis!
Disclaimer, I am the author of one of the libraries: sonnet. Although I tried it to make fair as possible, It might not be perfect for that perspective. Before getting into the performance of all, let me talk about the correctness.
- My fast JSON library in Go is now even faster and safer
-
Modification of json string without deserialisation into map/struct
github.com/sugawarayuuta/sonnet
- Show HN: Sonnet – The fastest JSON parser I can think of in Go
-
Toward the Fastest, Compatible JSON Decoder – Sonnet
Good morning.I hope this is not the wrong place to post… so let me introduce my first public Golang package. This is a JSON decoder called Sonnet ( https://github.com/sugawarayuuta/sonnet ) that has given faster results (at least in my environment) than Sonic - https://github.com/bytedance/sonic (which is said that it's the fastest) without the help of assembly!
JSON is a very well-known file format. It is used by everyone who does programming. However, it is also not uncommon to find problems with encoding/json and other third-party libraries. for more… (see https://github.com/sugawarayuuta/sonnet#problems-we-had )
I decided to create a new, standard library-compatible decoder that would be both easy to use and fast.
Thanks for reading, feel free to use, help, or ask questions, I look forward to hearing from you. All benchmarks and other information can be found in the link at the top.
-
Toward the Fastest, Compatible JSON Decoder - Sonnet
Good morning. Let me introduce my first public Go package. This is a JSON decoder called Sonnet ( https://github.com/sugawarayuuta/sonnet ) that has given faster results (at least in my environment) than Sonic (which is said that it's the fastest) without the help of assembly!
json
-
Go: the future encoding/json/v2 module
View on GitHub
-
Rust vs. Go in 2023
https://github.com/BurntSushi/rebar#summary-of-search-time-b...
Further, Go refusing to have macros means that many libraries use reflection instead, which often makes those parts of the Go program perform no better than Python and in some cases worse. Rust can just generate all of that at compile time with macros, and optimize them with LLVM like any other code. Some Go libraries go to enormous lengths to reduce reflection overhead, but that's hard to justify for most things, and hard to maintain even once done. The legendary https://github.com/segmentio/encoding seems to be abandoned now and progress on Go JSON in general seems to have died with https://github.com/go-json-experiment/json .
Many people claiming their projects are IO-bound are just assuming that's the case because most of the time is spent in their input reader. If they actually measured they'd see it's not even saturating a 100Mbps link, let alone 1-100Gbps, so by definition it is not IO-bound. Even if they didn't need more throughput than that, they still could have put those cycles to better use or at worst saved energy. Isn't that what people like to say about Go vs Python, that Go saves energy? Sure, but it still burns a lot more energy than it would if it had macros.
Rust can use state-of-the-art memory allocators like mimalloc, while Go is still stuck on an old fork of tcmalloc, and not just tcmalloc in its original C, but transpiled to Go so it optimizes much less than LLVM would optimize it. (Many people benchmarking them forget to even try substitute allocators in Rust, so they're actually underestimating just how much faster Rust is)
Finally, even Go Generics have failed to improve performance, and in many cases can make it unimaginably worse through -- I kid you not -- global lock contention hidden behind innocent type assertion syntax: https://planetscale.com/blog/generics-can-make-your-go-code-...
It's not even close. There are many reasons Go is a lot slower than Rust and many of them are likely to remain forever. Most of them have not seen meaningful progress in a decade or more. The GC has improved, which is great, but that's not even a factor on the Rust side.
-
Toward the Fastest, Compatible JSON Decoder - Sonnet
Add https://github.com/go-json-experiment/json
What are some alternatives?
sonic - A blazingly fast JSON serializing & deserializing library
Cargo - The Rust package manager
jx - json encoding and decoding
rebar - A biased barometer for gauging the relative speed of some regex engines on a curated set of tasks.
jingo - This package provides the ability to encode golang structs to a buffer as JSON very quickly.
screp - StarCraft - Brood War replay parser
v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io
frontmatter - Go library for detecting and decoding various content front matter formats
datafusion-ballista - Apache Arrow Ballista Distributed Query Engine
jsonbench - JSON benchmarks to compare different Go JSON implementations
book - The Rust Programming Language