Bug#585559: mutt: tokyocabinet is slower than gdbm

2012-04-21 Thread Arne Wichmann
So, what happened to these benchmarks? cu AW -- [...] If you don't want to be restricted, don't agree to it. If you are coerced, comply as much as you must to protect yourself, just don't support it. Noone can free you but yourself. (crag, on Debian Planet) Arne Wichmann (a...@linux.de) signat

Bug#585559: mutt: tokyocabinet is slower than gdbm

2011-04-27 Thread Antonio Radici
tag 585559 -moreinfo unreproducible tag 585559 +pending thanks We need to find a solution for this, I will run some benchmarks this weekend and see when and where this is reproducible. At that point I will be able to take a better decision with the proper data. Cheers Antonio -- To UNSUBSCRIB

Bug#585559: mutt: tokyocabinet is slower than gdbm

2010-12-30 Thread Antonio Radici
tag 585559 +unreproducible moreinfo thanks Hi, please provide the info requested by Christoph when you get a chance. anyway 1.5.20-9, which is being shipped with squeeze, is not using libtokyocabinet as far as I'm aware of. Cheers Antonio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@

Bug#585559: mutt: tokyocabinet is slower than gdbm

2010-06-14 Thread Christoph Berg
tags 585559 unreproducible thanks Re: Jon 2010-06-11 <20100611171553.23394.61340.report...@nobel.vault24.org> > The only conclusion I can draw from this is that the hcache backend is > mostly irrelevant to IMAP performance. Both are far superior to no > caching and the performance difference betwe

Bug#585559: mutt: tokyocabinet is slower than gdbm

2010-06-11 Thread Jon
Package: mutt Version: 1.5.20-8 Severity: normal There is no way in hell this should actually be true, but it is. I ran an actual benchmark to prove it. Maybe there is a bug in the current SID version of TC, maybe mutt isn't using it in an optimal manner, I don't know. But for the current way mu