Ripgrep – A new command line search tool
It would be interesting to benchmark how much mmap hurts when operating in a non-parallel mode.<p>I think a lot of the residual love for mmap is because it actually did give decent results back when single core machines were the norm.  However, once your program becomes multithreaded it imposes a lot of hidden synchronization costs, especially on munmap().<p>The fastest option might well be to use mmap sometimes but have a collection of single-thread processes instead of a single multi-threaded one so that their VM maps aren&#x27;t shared.  However, this significantly complicates the work-sharing and output-merging stages.  If you want to keep all the benefits you&#x27;d need a shared-memory area and do manual allocation inside it for all common data which would be a lot of work.<p>It might also be that mmap is a loss these days even for single-threaded... I don&#x27;t know.<p>Side note: when I last looked at this problem (on Solaris, 20ish years ago) one trick I used when mmap&#x27;ing was to skip the &quot;madvise(MADV_SEQUENTIAL)&quot; if the file size was below some threshold.  If the file was small enough to be completely be prefetched from disk it had no effect and was just a wasted syscall.  On larger files it seemed to help, though.