i have a few million files on my disk (a few kde and other checkouts make the majority) and each locate call takes at least two seconds (on a p4 @ 2.8 ghz). that's definitely too much.
i suppose one way to improve things would be storing the data hierarchically and searching it intelligently. of course this will get quite complicated for extended regexps, but this variation can be postponed, as it is expected to be slow. :)
the next step would be a full index (optionally only for whole words). not sure how far you would want to go, though. :}
Thanks for your report.
Can you gather some data, please? * Is locate I/O bound or CPU-bound? * Does configuring PRUNENAMES to exclude the .svn directories help significantly? * Does (LC_ALL=C locate....) help? If it helps, does it make locate I/O bound?
locate
PRUNENAMES
.svn
(LC_ALL=C locate
)
Is locate I/O bound or CPU-bound? almost completely cpu-bound. with cold disk caches it takes some percent more, but that's not relevant at that point. Does configuring PRUNENAMES to exclude the .svn directories help significantly? sure it does ... but not significantly enough. Does (LC_ALL=C locate ....) help? If it helps, does it make locate I/O bound? now, that's weird: with LC_CTYPE being C (whichever way achieved) it is reliably 10% slower than with en_US. i don't have any other locale settings.
Is locate I/O bound or CPU-bound?
almost completely cpu-bound. with cold disk caches it takes some percent more, but that's not relevant at that point.
Does configuring PRUNENAMES to exclude the .svn directories help significantly?
sure it does ... but not significantly enough.
Does (LC_ALL=C locate ....) help? If it helps, does it make locate I/O bound?
now, that's weird: with LC_CTYPE being C (whichever way achieved) it is reliably 10% slower than with en_US. i don't have any other locale settings.
Login to comment on this ticket.