Hey everyone - so I've taken simdjson's algorithm and improved upon it by resaturating the CPU registers with data instead of only operating on 64-bytes worth of string data at a time, as well as incorporated some compile-time hashmaps for the keys of data/memory locations being parsed. Let me know what you think! Also here's some benchmarks: https://github.com/RealTimeChris/Json-Performance
See the large number of JSON parse solutions and all the variants that there are with respect to broad properties of JSON, I wonder if it would be a good idea to implement a JSON parser generator.
In 2022, I spend some time looking at JSON parser for the ESP and I discovered that most libraries build an object structure. When processing a HTTP response, you first need to store the retrieved data into a string before it can be parsed into a tree of objects, before you can start parsing the contents of the response. This solution requires a lot of memory allocations. I started developing a solution that would be called from the HTTP request callback and immediately store the result of the response in the final a memory structures. See: https://github.com/FransFaase/ParsingJSONforHTTPClient
5 comments
[ 4.0 ms ] story [ 30.0 ms ] threadIn 2022, I spend some time looking at JSON parser for the ESP and I discovered that most libraries build an object structure. When processing a HTTP response, you first need to store the retrieved data into a string before it can be parsed into a tree of objects, before you can start parsing the contents of the response. This solution requires a lot of memory allocations. I started developing a solution that would be called from the HTTP request callback and immediately store the result of the response in the final a memory structures. See: https://github.com/FransFaase/ParsingJSONforHTTPClient