<<< Date Index >>>     <<< Thread Index >>>

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