ripgrep沒有得到大文件中的所有事件

-1

我試圖讓所有的事件在巨大的文件（37GB）。但它並沒有給我所有的結果。如何解決它在ripgrep搜索？ripgrep沒有得到大文件中的所有事件

rg "drive" file_name.txt -c 
5673 

// to compare: 
sift "drive" file_name.txt -c 
342894 

grep "drive" file_name.txt -c 
342894

UPDATE

的MacOS

2017-05-05 Sviatoslav

什麼是您的操作系統？你有沒有試過一個經常使用的GNU grep？ – RomanPerekhrest

這可能涉及到一些'ripgrep'的限制，我想（можетсвязаностем，что'ripgrep'неподдерживаетмногострочныйпоиск，ноэтотолькопредположение） – RomanPerekhrest

@RomanPerekhrest，據我所知，妳是正確的:(the_silver_searcher有問題大文件--github.com/ggreer/the_silver_searcher/issues/1038因此，篩選是今天最好的） – Sviatoslav

很可能得到正確的結果與--mmap

rg 'drive' file_name.txt -c --no-mmap 
5673 
rg 'drive' file_name.txt -c --mmap 
342894

但是，經過165秒（當篩入57秒，做到了）on macbook pro 8GB

UPDATE

原因是文中的<NUL>。在這種情況下，rg 123 -c file_name.txt停止進一步工作，不返回任何內容。 grep返回3.這個文件，你可以得到there

像二進制檢測文件更新

因爲<NUL>的。所以rg -a ...修復了這個問題。現在它更快（45秒）和篩選相同-a非常接近（48秒）。感謝@ BurntSushi5 for ripgrep！

2017-05-05 12:36:50 Sviatoslav

請注意，您正在搜索不適合內存的文件，因此您在此處報告的時間可能會產生誤導。例如，如果在運行ripgrep後運行篩選，那麼文件的一部分可能已經存在內存中，這將使搜索更快。還有其他一些事情會在這種規模下實際影響時間，例如，如果其他事情正在耗盡磁盤帶寬，那麼也會導致時間波動。 – BurntSushi5

@ BurntSushi5，我在安裝ripgrep之前多次使用該文件篩選過（並且速度相同）。 – Sviatoslav

沒錯，但是如果別的東西在使用磁盤帶寬（或者如果你的文件緩存改變了），那麼這可能會導致特定的ripgrep執行速度變慢。 '-a'製作的ripgrep更快的想法支持了這樣的想法，即你的基準測試...至少可以說是很奇怪的。 – BurntSushi5

回答