2 ms·
One thing I did benchmark was the use of memory maps for single file search (cf. `subtitles_literal`). In that case, it saved time (small, but measurable) to me
by burntsushi 10y ago
One thing I did benchmark was the use of memory maps for single file search (cf. `subtitles_literal`). In that case, it saved time (small, but measurable) to memory map the file than to incrementally read it. Memory maps were only slower in parallel search on large directories.
Thankfully, ripgrep makes it easy to switch between memory maps and incremental reading. So I can just do this for you right now on the spot:
$ time rg -j1 PM_SUSPEND | wc -l
335
real 0m0.406s
user 0m0.350s
sys 0m0.293s
$ time rg -j1 PM_SUSPEND --mmap | wc -l
335
real 0m0.482s
user 0m0.380s
sys 0m0.317s
Note that this is on a Linux x64 box. I bet you'd get completely different results on a different OS.
- bodyfour 10y agoInteresting that user time went up as well.. not sure if that's significant. I guess it's not too surprising that mmap isn't much of a win these days for anything... SIMD can copy a memory page pretty fast these days. I just installed rg from homebrew and it's quite impressive... about 2.5x faster than ag on my macbook pro. Interestingly I get another 25% improvement by falling back to -j3 even though I'm on a quad-core machine. Not sure what is bottlenecking since it's all in cache.
- burntsushi 10y agoYeah, figuring out the optimal thread count has always seemed like a bit of a black art to me. I can pretty reliably figure it out for my system (which has 8 physical cores, 16 logical), but it's hard to generalize that to others. -j3 will spawn 3 workers for searching while the main thread does directory traversal. It sounds like I should do `num_cpus - 1` for the default `-j` instead of `num_cpus`.