-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
@jessegrosjean wrote this from #244 (comment)
@BurntSushi I'm blown away at the speed of ripgrep in terminal. I'm trying not to loose that speed when running from my app. I think the JSON format (as I understand it) makes large searches that rg
handles easily from the terminal near impossible to perform using the JSON API.
I think including a full line of context with each match is just too much bandwidth for some cases.
For example:
My test case is pathological–search for e
in my home directory. It generates 4,655,585 results. Crazy, but this is just the kind of thing that a user might try to see if an app works and isn't buggy. And in fact it's what made me so impressed with ripgrep. When I run ripgrep on my home directory I see:
time rg e > NULL
real 0m2.381s
user 0m2.226s
sys 0m1.615s
Wow! Fast. But then if I do:
time rg --vimgrep e > NULL
My computer starts to die. I kill the process after 20 seconds and starting to run out of memory. I "think" the problem is that unlike the default command --vimgrep
returns a full line for each result. It’s just to much bandwidth when you have many results.
What you're asking for really sounds like a new "preview" type feature, which is similar to, but different from, what --max-columns achieves. --max-columns is really about limiting the length of lines reported, where as a hypothetical preview feature is quite a bit more complex than that and will need to account for windowing every match, of which there may be multiple.
I was asking for this, but I think you are correct, it’s to complicated, and would still require to much overlapping bandwidth in some cases. For example imagine the case where the user searches for e
in a giant minified.js file.
Better I think is to just provide some options for what data is included in “match” (from the JSON API). What about an option to just omit the “match.lines” value?
My app could then generate the initial list of results quickly (by omitting the “lines” values). And then lazily (as matches are scrolled through the view) load and highlight the actually matched text.