Thomas Glanzmann wrote: [Mon Mar 13 2006, 03:17:42PM EST] > > exception that I've been testing with gdbm instead of db4. Just to > > I use qdbm not db4. Because it is the fastet of the three supported and > it is the only who does support compression which reduces header cache > size to 1/5 of the original header cache in my usage scenario. gdbm is > faster than db4. There's some confusion between the configuration you posted and your statement here. The configuration that you showed in your previous email showed --without-qdbm --without-gdbm. Additionally you were setting header_cache_pagesize which only exists in init.h for HAVE_GDBM || HAVE_DB4. So I assume you are referring to your usual configuration instead of your testing configuration? > > The second run took 5 seconds, third run took 0.5 seconds, clearly > > using the cache. > > at seems so but it could be also the buffer cache of the filesystem. But > killing the cache short after creation and do it again will give you the > strong prove that you use it. I also had a patch which gathers hit/miss > statics. Whatever. I'm sorry, but I don't understand what you're saying in light of what I stated. My testing involves three runs. The first warms the filesystem buffer cache so that it is not a factor. After the first run, I remove the mutt header_cache and perform two additional runs. You're right that timing is a poor method of determining whether the header_cache is working, but the discrepancy in times when caching is used is significant. Aron
Attachment:
pgpOxZELNkRNU.pgp
Description: PGP signature