Re: header_cache broken in cvs
Hello Aron,
> 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?
My test setup was with gdbm, but I usally use qdbm with the following
configuration:
set maildir_header_cache_verify=no
set header_cache_compress=yes
folder-hook . 'set header_cache="/tmp/sithglan-hcache/"'
folder-hook 'Maildir$' 'set header_cache=""'
folder-hook '.lists.cip.system$' 'set header_cache=""'
folder-hook '.lists.cip.problems$' 'set header_cache=""'
I supplied three lines in my previous eMail one for each database
backend. I tested all database backends myself:
./configure --enable-hcache --enable-imap --with-slang --with-ssl
./configure --enable-hcache --enable-imap --with-slang --with-ssl
--without-qdbm
./configure --enable-hcache --enable-imap --with-slang --with-ssl
--without-qdbm --without-gdbm
I intended to use qdbm for my tests yesterday but qdbm libs were not in
my path that why the configure script felt back on gdbm.
> 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.
I see. So no buffer cache issues involved.
> 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.
But it works in pratice. :-)
Thomas