4 ms·
Not sure its a fair comparison. I mean in his comparison qgrep finds a match at line 44478 where ripgrep says its line 53924. Then there's the obvious left-out
by asdf098asdf098 8y ago
Not sure its a fair comparison.
I mean in his comparison qgrep finds a match at line 44478 where ripgrep says its line 53924.
Then there's the obvious left-out of time it takes for qgrep to populate its cache.
Seems like an apples and oranges comparison to me.
- burntsushi 8y agoOn my system, the line number reported by qgrep is correct and matches ripgrep. I don't know why the article's example is off, but I'd probably assume it was a copy & paste error. > Seems like an apples and oranges comparison to me. This kind of misses the point. The OP is perfectly up front about this. It's not an apples to apples comparison in the sense that the tools are doing roughly similar algorithmic work internally, but it is a decent apples to apples comparison in terms of the user experience. That is, searches are much faster when you have a pre-computed index. With that said, getting the user experience around keeping the index up to date is definitely a key component of this, and the article doesn't really explore that aspect. But I don't think index creation/update time should be included search benchmarks, since the whole point of a tool like this is that creating or updating the index should be a relatively cheap and infrequent thing compared to the searches executed against the index.