With directory structures not cached in RAM, plocate probably beats find, especially on disks with high seek times (HDDs), but does of course require an up-to-date database.Ī parallelized find might give better results on systems which profit from command queuing and can request data in parallel. zsh globs ( **/* and extended versions): Generally very slow, but can be elegant in scripts (~3 seconds).fd ( fdfind -type f on Debian): Not as fast as expected (~0.7 seconds).ripgrep ( rg -files -no-ignore -hidden): A good bit faster, but still very slow (~0.5 seconds).mlocate ( mlocate -regexp "^$PWD"): Interestingly faster than the non-regexp queries (~ 5 seconds).plocate ( plocate -regexp "^$PWD") (GNU find ( find -type f): Surprisingly, find is often the fastest tool (~ 0.01 seconds).Here are some results for just trying to find all files in a sample directory (~200.000 files) in descending speed order: It's harder to - sorry - locate a good find alternative and the result very much depends on the specific queries. Most of the time plocate is multiple orders of magnitude faster than mlocate. mlocate takes an almost constant 35 to 40 seconds to query the same database in all tested cases. In a database of about 61 million files plocate answers specific queries (a couple of hundred results) in the order of 0.01 to 0.2 seconds and only becomes much slower (> 100 seconds) for very unspecific queries with millions of results. I compared the commonly used mlocate and plocate. (GNU) find often still seems to be hard to beat for tools which don't require an index. Tl dr: plocate is a very fast alternative to mlocate in most cases. The existence of the -depth option hints at the possibility, but alas.Īs of early 2021 I evaluated a few tools for similar use cases and integration with fzf: Why doesn't find have this search order as a built-in feature? Maybe because it would be complicated/impossible to implement if you assumed that the redundant traversal was unacceptable. Note that the inherent redundancy involved (each pass will have to traverse the folders processed in previous passes) will largely be optimized away through disk caching. Here's an example script to automate this process (Ctrl-C when you see what you want): (įind -mindepth $i -maxdepth $i -iname "$TARGET" This ensures that you don't waste up-front time looking through the depths of massive sub-trees when what you are looking for is more likely to be near the base of the hierarchy. The first few iterations are likely to return instantaneously. Repeat with increasing depths until you find what you are looking for, or you get tired of looking. In the former case, write notes (documentation), in the latter, ask? Conventions, standards and consistency can help a lot.Ī tactic that I use is to apply the -maxdepth option with find: find -maxdepth 1 -iname "*target*" Maybe you are searching because you have forgotten where something is or were not told.
database= Specifies the path of databases to search in. U Ĭreate slocate database starting at path. Read the man page and make use of whatever options are appropriate to your task. For example '-maxdepth 5' Speeding up locateĮnsure it is indexing the locations you are interested in. For me, this improves the speed of 'find' a lot. Use pipelines to defer some selection criteria if that is more efficient.Īlso, you can limit the depth of search. Simplify the selection criteria as much as possible. Search fewer places, instead of find / … use find /path/to/project … where possible. I have a "sources" script so that I can write commands like grep variable $(sources programname). These can be a fast way to extract a list of files (and their locations) write a script that makes use of this information to locate files. In other projects you may have something similar. In a C project you'd typically have a Makefile. Generally, source for a project is likely to be in one place, perhaps in a few subdirectories nested no more than two or three deep, so you can use a (possibly) faster command such as (cd /path/to/project ls *.c */*.c */*/*.c)
0 kommentar(er)
