[deleted]
A Faster Alternative to Jq
121–130 of 281 posts
Re: A Faster Alternative to Jq
#122Earlier quoted context omitted.
Also as someone who looks at latency charts too much, what happens is a request does a lot in series and any little ms you can knock off adds up. You save 10ms by saving 10 x 1ms. And if you are a proxyish service then you are a 10ms in a chain that might be taking 200 or 300ms. It is like saving money, you have to like cut lots of small expenses to make an impact. (unless you move etc. but once you done that it is s…
Wait what? I don't get why performance improvement implies reliability and incident improvement. For example, doing dangerous thing might be faster (no bound checks, weaker consistency guarantee, etc), but it clearly tend to be a reliability regression.
Less OOMs, less timeouts, less noisy neighbors problems affecting other apps
Re: A Faster Alternative to Jq
#123I wonder so often about many new CLI tools whose primary selling point is their speed over other tools. Yet I personally have not encountered any case where a tool like jq feels incredibly slow, and I would feel the urge to find something else. What do people do all day that existing tools are no longer enough? Or is it that kind of "my new terminal opens 107ms faster now, and I don't notice it, but I simply feel bet…
Race between ripgrep and ugrep is entertaining.
Re: A Faster Alternative to Jq
#124Quick question: Isn't the construction of a NFA - DFA a O(2^n) algorithm? If a JSON file has a couple hundred values, its equivalent NFA will have a similar amount, and the DFA will have 2^100 states, so I must be missing something.
theory is one thing but the cpu cache is the real bottleneck here... here is a small visual breakdown of how these arrays look in memory and why pointer chasing is so expensive compared to the actual logic: https://vectree.io/c/json-array-memory-indexing
basically the double jump to find values in the heap is what slows down these tools most
Re: A Faster Alternative to Jq
#125Earlier quoted context omitted.
Still, jq is run a whole lot more than it used to be due to coding agents, so every bit helps. The vast majority of Linux kernel performance improvement patches probably have way less of a real world impact than this.
> The vast majority of Linux kernel performance improvement patches probably have way less of a real world impact than this. unlikely given that the number they are multiplying by every improvement is far higher than "times jq is run in some pipeline". Even 0.1% improvement in kernel is probably far far higher impact than this
Jq is run a ton by AIs, and that is only increasing.
Re: A Faster Alternative to Jq
#126The data viz of the benchmarks is really rough. I think you’d get a lot of leverage out of rebuilding it and using colors and/or shapes to extract additional dimensions. Nobody wants to scan through raw file paths as labels to try and figure out what the hell the results are
Re: A Faster Alternative to Jq
#127When initially opening the page it had broken colors in light mode. For anyone else encountering it: switch to dark mode and then back to light mode to fix it.
Modern programmers these days just give a shit about user experience. Better to just load up in reader mode.
Re: A Faster Alternative to Jq
#128I wonder so often about many new CLI tools whose primary selling point is their speed over other tools. Yet I personally have not encountered any case where a tool like jq feels incredibly slow, and I would feel the urge to find something else. What do people do all day that existing tools are no longer enough? Or is it that kind of "my new terminal opens 107ms faster now, and I don't notice it, but I simply feel bet…
We parse JSON responses for dashboards, alerting, etc. Thousands of nodes, depending on the resolution of your monitoring you could see improvements here.
Re: A Faster Alternative to Jq
#129Earlier quoted context omitted.
Also as someone who looks at latency charts too much, what happens is a request does a lot in series and any little ms you can knock off adds up. You save 10ms by saving 10 x 1ms. And if you are a proxyish service then you are a 10ms in a chain that might be taking 200 or 300ms. It is like saving money, you have to like cut lots of small expenses to make an impact. (unless you move etc. but once you done that it is s…
Wait what? I don't get why performance improvement implies reliability and incident improvement. For example, doing dangerous thing might be faster (no bound checks, weaker consistency guarantee, etc), but it clearly tend to be a reliability regression.
First, if a performance optimization is a reliability regression, it was done wrong. A bounds check is removed because something somewhere else is supposed to already guaratee it won't be violated, not just in a vacuum. If the guarantee stands, removing the extra check makes your program faster and there is no reliability regression whatsoever.
And how does performance improve reliability? Well, a more performant service is harder to overwhelm with a flood of requests.
Re: A Faster Alternative to Jq
#130When initially opening the page it had broken colors in light mode. For anyone else encountering it: switch to dark mode and then back to light mode to fix it.
I think this has just been fixed. A bit of dark mode was leaking into light in the css.
It’s still broken for me at this point. White link text on nearly white background. Impossible to read. Safari on my iPad.