Yes

I often have to pluck out attributes from streams of json records (1 json object per line) - often millions/billions.

jq is almost always the bottleneck in the pipeline at 100% CPU - so much so that we often add an fgrep to the left side of the pipeline to minimize the input to jq as much as possible.

It's very slow. It was immediately standing out in our automated tests when we've added a json protocol to our system and used jq to test some assertions.

jq is pretty fast in my experience. But there have been cases where I've wanted it to be faster (dealing with a 90GB JSON file).

The main weakness seems to be streaming use cases (not having the whole file in memory at once). These are supported, but the syntax is quite awkward.

Yes. I was looking to embed it in a tool, but decided against it after looking at its implementation. It parses the expression with a stack and executes it directly, and its JSON parsing is much the same. I doubt the parsing would be close to competitive with RapidJSON, let alone simd-json. The conditionals and pointer chasing of such an implementation are stumbling blocks to performance.

The C code is clean enough as C code goes, but fairly monolithic. And it’s C, so it’s not noticeably slow until you start processing GB. But it would probably take a rewrite to improve its performance significantly.

Nobody said that jq is slow.