6 ms·

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a lot in an ad hoc manner on really large files I switch to rg. But that is only in the handful of cases.

dalvrosa 6mo ago
Fair, but agentic tooling can benefit quite a lot from this Opencode, ClaudeCode, etc, feel slow. Whatever make them faster is a win :)
- jamespo 6mo ago
  It's not running jq locally that's causing that
- httpsterio 6mo ago
  The 2ms it takes to run jq versus the 0.2ms to run an alternative is not why your coding agent feels slow.
  - jmalicki 6mo ago
    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.
    - PunchyHamster 6mo ago
      > 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
      - jmalicki 6mo ago
        Jq is run a ton by AIs, and that is only increasing.
        foobarian 6mo ago
        I can't take seriously any talk about performance if the tools are going to shell out. It's just not a bottleneck.
montroser 6mo ago
Then this is for the handful of cases for you. When it matters it matters.
lemagedurage 6mo ago
True. I feel like the main way a tool could differentiate from jq is having more intuitive syntax and many real world examples to show off the syntax.
- roland35 6mo ago
  For better or worse, Claude is my intuitive interface to jq. I don't use it frequently, and before I would have to look up the commands every time, and slowly iterate it down to what I needed.
- mpalmer 6mo ago
  The syntax makes perfect sense when you understand the semantics of the language. Out of curiosity, have you read the jq manpage? The first 500 words explain more or less the entire language and how it works. Not the syntax or the functions, but what the language itself is/does. The rest follows fairly easily from that.
mikojan 6mo ago
> I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. > > 9/10 whatever tooling you are using now will be perfectly fine Are you working in frontend? On non-trivial webapps? Because this is entirely wrong in my experience. Performance issues are the #1 complaint of everyone on the frontend team. Be that in compiling, testing or (to a lesser extend) the actual app.
- ffsm8 6mo ago
  Uh, I've worked for a few years as a frontend dev, as in literal frontend dev - at that job my responsibility started at consuming and ended at feeding backend APIs, essentially. From that I completely agree with your statement - however, you're not addressing the point he makes which kinda makes your statement completely unrelated to his point 99.99% of all performance issues in the frontend are caused by devs doing dumb shit at this point The frameworks performance benefits are not going to meaningfully impact this issue anymore, hence no matter how performant yours is, that's still going to be their primary complaint across almost all complex rwcs And the other issue is that we've decided that complex transpiling is the way to go in the frontend (typescript) - without that, all built time issues would magically go away too. But I guess that's another story. It was a different story back when eg meteorjs was the default, but nowadays they're all fast enough to not be the source of the performance issues
- deleted 6mo ago
  [deleted]
- lelandfe 6mo ago
  There are some really fast tools out there for compiling FE these days, and that's probably to what they refer. Testing is still a slog.
- g947o 6mo ago
  Worked on front end for years. Rarely ever hear people talking about performance issues. I was among the very few people who knew how to use the dev tools to investigate memory leak or heard of memlab. Either the team I worked at was horrible, or you are from Google/Meta/Walmart where either everyone is smart or frondend performance is directly related to $$.
j1elo 6mo ago
Whenever you have this kind of impressions on some development, here are my 2 cents: just think "I'm not the target audience". And that's fine. The difference between 2ms and 0.2ms might sound unneeded, or even silly to you. But somebody, somewhere, is doing stream processing of TB-sized JSON objects, and they will care. These news are for them.
- mememememememo 6mo ago
  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 small numerous things thay add up) Also performance improvements on heavy used systems unlocks: Cost savings Stability Higher reliability Higher throughput Fewer incidents Lower scaling out requirements.
  - lock1 6mo ago
    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.
    - cwaffles 6mo ago
      Less OOMs, less timeouts, less noisy neighbors problems affecting other apps
    - spiffyk 6mo ago
      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.
Koschi13 6mo ago
Maybe look at it from another perspective. Better performance == less CPU cycles wasted. Consider how many people use jq daily and think about how much energy could be saved by faster implementations. In times like this where energy is becoming more scarce we should think about things like this.
- gpvos 6mo ago
  I agree, but in this age of widespread LLM use, that's only marginal.
- mpalmer 6mo ago
  > Consider how many people use jq daily and think about how much energy could be saved by faster implementations. Say a number; make a real argument. Don't just wave your hand and say "just imagine how right I could be about this vague notion if we only knew the facts"
Hendrikto 6mo ago
I get the sentiment, but everybody thinks that, and in aggregate, you get death by a thousand paper cuts. It’s the same sentiment as “Individuals don’t matter, look at how tiny my contribution is.”. Society is made up of individuals, so everybody has to do their part. > 9/10 whatever tooling you are using now will be perfectly fine. It is not though. Software is getting slower faster than hardware is getting quicker. We have computers that are easily 3–4+ orders of magnitudes faster than what we had 40 years ago, yet everything has somehow gotten slower.
raverbashing 6mo ago
Yes I don't think I remember one case where jq wasn't fast enough Now what I'd really want is a jq that's more intuitive and easier to understand
- latexr 6mo ago
  > Now what I'd really want is a jq that's more intuitive and easier to understand Unfortunately I don’t recall the name, but there was something submitted to HN not too long ago (I think it was still 2026) which was like jq but used JavaScript syntax.
mattbis 6mo ago
Was about to post exactly this... It is impressive engineering wise, but for data and syntax, ease of use or all the great features, I care about that more. Speed isn't that important to me for a lot of these tools. If I/you was working with JSON of that size where this was important, id say you probably need to stop using JSON! and some other binary or structured format... so long as it has some kinda tooling support. And further if you are doing important stuff in the CLI needing a big chain of commands, you probably should be programming something to do it anyways... that's even before we get to the whole JSON isn't really a good data format whatsoever... and there are many better ways. The old ways or the new ways. One day I will get to use my XSLT skills again :D
phillipcarter 6mo ago
I agree for some things, but not for tools or "micro-software" like jq that can get called a LOT in an automated process. Every order of magnitude saved for the latter category can be meaningful.
sramsay 6mo ago
I absolutely understand what you're saying. It makes complete sense. But I will never, ever shake the sense that software that isn't as fast as possible is offensive, immoral, delinquent -- the result of sloth, lassitude, lack of imagination, and a general hostility toward our noble Art. "Fast enough" will always bug me. "Still ahead of network latency" will always sound like the dog ate your homework. I understand the perils of premature optimization, but not a refusal to optimize. And I doubt I'm alone.

dalvrosa 6mo ago

Fair, but agentic tooling can benefit quite a lot from this Opencode, ClaudeCode, etc, feel slow. Whatever make them faster is a win :)

jamespo 6mo ago
It's not running jq locally that's causing that
httpsterio 6mo ago
The 2ms it takes to run jq versus the 0.2ms to run an alternative is not why your coding agent feels slow.
- jmalicki 6mo ago
  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.
  - PunchyHamster 6mo ago
    > 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
    - jmalicki 6mo ago
      Jq is run a ton by AIs, and that is only increasing.
      - foobarian 6mo ago
        I can't take seriously any talk about performance if the tools are going to shell out. It's just not a bottleneck.

montroser 6mo ago

Then this is for the handful of cases for you. When it matters it matters.

lemagedurage 6mo ago

True. I feel like the main way a tool could differentiate from jq is having more intuitive syntax and many real world examples to show off the syntax.

roland35 6mo ago
For better or worse, Claude is my intuitive interface to jq. I don't use it frequently, and before I would have to look up the commands every time, and slowly iterate it down to what I needed.
mpalmer 6mo ago
The syntax makes perfect sense when you understand the semantics of the language. Out of curiosity, have you read the jq manpage? The first 500 words explain more or less the entire language and how it works. Not the syntax or the functions, but what the language itself is/does. The rest follows fairly easily from that.

mikojan 6mo ago

> I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. > > 9/10 whatever tooling you are using now will be perfectly fine Are you working in frontend? On non-trivial webapps? Because this is entirely wrong in my experience. Performance issues are the #1 complaint of everyone on the frontend team. Be that in compiling, testing or (to a lesser extend) the actual app.

ffsm8 6mo ago
Uh, I've worked for a few years as a frontend dev, as in literal frontend dev - at that job my responsibility started at consuming and ended at feeding backend APIs, essentially. From that I completely agree with your statement - however, you're not addressing the point he makes which kinda makes your statement completely unrelated to his point 99.99% of all performance issues in the frontend are caused by devs doing dumb shit at this point The frameworks performance benefits are not going to meaningfully impact this issue anymore, hence no matter how performant yours is, that's still going to be their primary complaint across almost all complex rwcs And the other issue is that we've decided that complex transpiling is the way to go in the frontend (typescript) - without that, all built time issues would magically go away too. But I guess that's another story. It was a different story back when eg meteorjs was the default, but nowadays they're all fast enough to not be the source of the performance issues
deleted 6mo ago
[deleted]
lelandfe 6mo ago
There are some really fast tools out there for compiling FE these days, and that's probably to what they refer. Testing is still a slog.
g947o 6mo ago
Worked on front end for years. Rarely ever hear people talking about performance issues. I was among the very few people who knew how to use the dev tools to investigate memory leak or heard of memlab. Either the team I worked at was horrible, or you are from Google/Meta/Walmart where either everyone is smart or frondend performance is directly related to $$.

j1elo 6mo ago

Whenever you have this kind of impressions on some development, here are my 2 cents: just think "I'm not the target audience". And that's fine. The difference between 2ms and 0.2ms might sound unneeded, or even silly to you. But somebody, somewhere, is doing stream processing of TB-sized JSON objects, and they will care. These news are for them.

mememememememo 6mo ago
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 small numerous things thay add up) Also performance improvements on heavy used systems unlocks: Cost savings Stability Higher reliability Higher throughput Fewer incidents Lower scaling out requirements.
- lock1 6mo ago
  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.
  - cwaffles 6mo ago
    Less OOMs, less timeouts, less noisy neighbors problems affecting other apps
  - spiffyk 6mo ago
    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.

Koschi13 6mo ago

Maybe look at it from another perspective. Better performance == less CPU cycles wasted. Consider how many people use jq daily and think about how much energy could be saved by faster implementations. In times like this where energy is becoming more scarce we should think about things like this.

gpvos 6mo ago
I agree, but in this age of widespread LLM use, that's only marginal.
mpalmer 6mo ago
> Consider how many people use jq daily and think about how much energy could be saved by faster implementations. Say a number; make a real argument. Don't just wave your hand and say "just imagine how right I could be about this vague notion if we only knew the facts"

Hendrikto 6mo ago

I get the sentiment, but everybody thinks that, and in aggregate, you get death by a thousand paper cuts. It’s the same sentiment as “Individuals don’t matter, look at how tiny my contribution is.”. Society is made up of individuals, so everybody has to do their part. > 9/10 whatever tooling you are using now will be perfectly fine. It is not though. Software is getting slower faster than hardware is getting quicker. We have computers that are easily 3–4+ orders of magnitudes faster than what we had 40 years ago, yet everything has somehow gotten slower.

raverbashing 6mo ago

Yes I don't think I remember one case where jq wasn't fast enough Now what I'd really want is a jq that's more intuitive and easier to understand

latexr 6mo ago
> Now what I'd really want is a jq that's more intuitive and easier to understand Unfortunately I don’t recall the name, but there was something submitted to HN not too long ago (I think it was still 2026) which was like jq but used JavaScript syntax.

mattbis 6mo ago

Was about to post exactly this... It is impressive engineering wise, but for data and syntax, ease of use or all the great features, I care about that more. Speed isn't that important to me for a lot of these tools. If I/you was working with JSON of that size where this was important, id say you probably need to stop using JSON! and some other binary or structured format... so long as it has some kinda tooling support. And further if you are doing important stuff in the CLI needing a big chain of commands, you probably should be programming something to do it anyways... that's even before we get to the whole JSON isn't really a good data format whatsoever... and there are many better ways. The old ways or the new ways. One day I will get to use my XSLT skills again :D

phillipcarter 6mo ago

I agree for some things, but not for tools or "micro-software" like jq that can get called a LOT in an automated process. Every order of magnitude saved for the latter category can be meaningful.

sramsay 6mo ago

I absolutely understand what you're saying. It makes complete sense. But I will never, ever shake the sense that software that isn't as fast as possible is offensive, immoral, delinquent -- the result of sloth, lassitude, lack of imagination, and a general hostility toward our noble Art. "Fast enough" will always bug me. "Still ahead of network latency" will always sound like the dog ate your homework. I understand the perils of premature optimization, but not a refusal to optimize. And I doubt I'm alone.