Your measurement procedure is wrong because the `journalctl` command is doing something different. It isn't just reading a plain file, it is reading a binary file. On the other hand, `grep` and `rg` are reading straight text.
> it seems difficult to believe that journalctl --grep can be faster.
Why? It could be doing it in parallel. One thread starts reading at position 0 and reads till N, another starts at N+1 and reads to 2N, etc. That's a much faster read operation. But I'm guessing and have no idea if this is what is actually being done or not.
P.S.: I know. As I specified in my earlier comment, I get burned with build artifacts and project logs. Things that most people would have in their .gitignore files but you can sure expect to grep through when debugging.
Their measurement isn't wrong. It's demonstrating the exact point in question: that if the logs were just stored in plain text, then grepping them would be an order of magnitude faster (or multiple orders of magnitude in the case of ripgrep) than whatever `journalctl --grep` is doing.
How it's doing the search is irrelevant. What's being measured here is the user experience. This isn't some kind of attempt to do an apples-to-apples grep comparison. This is about how long you have to wait for a search of your logs to complete.
Check out the filetype of the journal files
Your measurement procedure is wrong because the `journalctl` command is doing something different. It isn't just reading a plain file, it is reading a binary file. On the other hand, `grep` and `rg` are reading straight text. Why? It could be doing it in parallel. One thread starts reading at position 0 and reads till N, another starts at N+1 and reads to 2N, etc. That's a much faster read operation. But I'm guessing and have no idea if this is what is actually being done or not.P.S.: I know. As I specified in my earlier comment, I get burned with build artifacts and project logs. Things that most people would have in their .gitignore files but you can sure expect to grep through when debugging.