Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Faster Alternative to Jq

micahkepe.com

Post reply on HN
Print view View original

111–120 of 281 posts

Re: A Faster Alternative to Jq

#111

Post by anonymoushn »

rennokki wrote: post #71
nchmy wrote: post #14

Earlier quoted context omitted.

This isn't for you then > The query language is deliberately less expressive than jq's. jsongrep is a search tool, not a transformation tool-- it finds values but doesn't compute new ones. There are no filters, no arithmetic, no string interpolation. Mind me asking what sorts of TB json files you work with? Seems excessively immense.

> Uses jq for TB json files > Hadoop: bro > Spark: bro > hive: bro > data team: bro

are those tools known for their fast json parsers?

Re: A Faster Alternative to Jq

#112

Post by f311a »

rennokki wrote: post #71
nchmy wrote: post #14

Earlier quoted context omitted.

This isn't for you then > The query language is deliberately less expressive than jq's. jsongrep is a search tool, not a transformation tool-- it finds values but doesn't compute new ones. There are no filters, no arithmetic, no string interpolation. Mind me asking what sorts of TB json files you work with? Seems excessively immense.

> Uses jq for TB json files > Hadoop: bro > Spark: bro > hive: bro > data team: bro

JQ is very convenient, even if your files are more than 100GB. I often need to extract one field from huge JSON line files, I just pipe jq to it to get results. It's slower, but implementing proper data processing will take more time.

Re: A Faster Alternative to Jq

#113

Post by PunchyHamster »

jmalicki wrote: post #77
httpsterio wrote: post #60

Earlier quoted context omitted.

The 2ms it takes to run jq versus the 0.2ms to run an alternative is not why your coding agent feels slow.

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

Re: A Faster Alternative to Jq

#115

Post by raverbashing »

1a527dd5 wrote: post #43

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…

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

Re: A Faster Alternative to Jq

#116

Post by 1123581321 »

xeyownt wrote: post #101
merlindru wrote: post #84

Earlier quoted context omitted.

this is a bad faith take. i think the website is really cool and doesn't reek of slop at all. what makes you think differently?

Same. And who cares if it's vibe-coded or not. Since when do we care more on the how than on the what? Are people looking at how a tool was coded before using it, as if it would accelerate confidence?

It’s a heuristic to approach a program a bit warily as the length of the documentation likely outpaces how thoroughly it was designed and tested.

Re: A Faster Alternative to Jq

#117

Post by arjie »

Thank you. Very cool. Going to try embedding this into my JSON viewer. One thing I’ve struggled with is that live querying in the UI is constrained by performance.

Re: A Faster Alternative to Jq

#118

Post by chrisweekly »

g947o wrote: post #105
mikojan wrote: post #62

Earlier quoted context omitted.

> 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…

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 $$.

"performance is directly related to $$"

It is. Company size is moot. See https://wpostats.com for starters.

Re: A Faster Alternative to Jq

#119

Post by alexellisuk »

Quick comment for the author.

Just added this new tool to arkade, along with the existing jq/yq.

No Arm64 for Darwin.. seriously? (Only x86_64 darwin.. it's a "choice")

No Arm64 for Linux?

For Rust tools it's trivial to add these. Do you think you can do that for the next release?

https://github.com/micahkepe/jsongrep/releases/tag/v0.7.0

Re: A Faster Alternative to Jq

#120

Post by alexellisuk »

steelbrain wrote: post #21

Surprised to see that there's no official binaries for arm64 darwin. Meaning macOS users will have to run it through the Rosetta 2 translation layer.

Just hit this too:

https://news.ycombinator.com/item?id=47542182

The reason I was interested, was adding the new tool to arkade (similar to Brew, but more developer/devops focused - downloads binaries)

The agent found no Arm binaries.. and it seemed like an odd miss for a core tool

https://x.com/alexellisuk/status/2037514629409112346?s=20

Post reply on HN