Apparently this bug is still a thing, I thought the maintainer closed it. I'm glad to hear I am not crazy and other people saw this, cause I was pretty skeptical of my own benchmarks at one point. Which is part of why I had benchmarks, because by all logic gdbm should have been faster!
At some point in the past 4 years I discovered this fixed it: set header_cache_compress=no But I also just disabled that line and did some tests. With an 800k message box, TC is about 2x faster with compression. (25s v. 50s) I did not time creating the cache. At 80k folder size I'm not sure I measured a statistically significant difference. But at the timescale of about 2-3s, the no compression was marginally faster by ~1s. If I simply double my original numbers in the first messsage to reflect a mailbox twice as big, TC is basically compariable to the originnal GDBM times. (Note: the 800k message box is completely unreasonable and I really need to prune my copy of LKML...) Back when I opened this it was *really* distinct that TC was slower than GDBM and then turning off compression fixed it. I don't see that anymore, so I can only assume there was something fixed somewhere in the past 4 years. I'm not really interested in rebuilding against GDBM just to benchmark it and be sure. Not sure how to close bug, but as the OP I have to say this was probably a problem with TC w/ compression and it was probably fixed years ago. -- Jon Kernel Archaeologist X(7): A program for managing terminal windows. See also screen(1). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
