Apparently, though unproven, at 18:29 on Wednesday 17 November 2010, Stroller did opine thusly:
> On 17/11/2010, at 3:07pm, Alan McKinnon wrote: > >> ... > >> Just ran updatedb with mlocate and it was blindingly fast! Is that > >> normal or did it not run and tricked me! ;-) > > > > /usr/share/doc/mlocate-0.23.1/README.bz2 > > > > Why do so many people ask questions without reading the docs FIRST? > > I'm not sure what that demonstrates. > > As I read that, it implies that mlocate's indexing will be fast because it > uses the existing database during its updatedb operation. I'm going to > have to read more about that, as it sounds rather clever. > > However Mick and myself were expressing surprise at the speed of mlocate's > *first* run, when no mlocate.db would be existent. I can think of two things worthy of investigation, neither have much documentation to back them up. unmerging slocate does not remove slocate.db as he build didn't put it there. When mlocate first runs, it might be checking so slocate.db if mlocate.db doesn't exist, and use that for the initial db. You may have configured updatedb.conf to include filesystems that would not normally be indexed and then told etc-update to overwrite this with the new version from mlocate. As a data point, my notebook is fairly average and takes 4 minutes to make it's way through 62G of stuff (excluding removable and network drives) -- alan dot mckinnon at gmail dot com
