Apparently, though unproven, at 00:26 on Thursday 18 November 2010, Mick did opine thusly:
> > Conclusions: > > > > > > 1. mlocate is slow at building it's db from scratch - about 250% as long > > as slocate on the same task. > > 2. mlocate is faster at reindexing a largely-unchanged fs - it does it in > > about 66% of the time slocate took. > > 3. mlocate is insanely quick at reindexing a db that is in cache. > > > > > > > > #1 is are - most systems will only do it once > > #3 is silly and does not represent anything close to reality > > #2 is pretty realistic and a 33% performance boost is significant > > > > > > > > I have no idea where the speed increase in #3 comes from. This is an ext4 > > fs - does ext4 keep an in-memory hash of inodes it reads? It seems to me > > that would be a very clever and very useful thing for an fs to do. > > No. 3 is what made me sent my first post. I was almost convinced that I > did something wrong, because no sooner had I hit return it completed. I see that. In contrast to what I said in my first post, mlocate does seem to have found a way to speed up those access. It's not just kernel caching - it's 5 times faster than slocate even with virtually nothing to re-index -- alan dot mckinnon at gmail dot com
