On Sunday, 07 September 2008 at 16:12, Thomas Roessler wrote: > Sorting by to or from header is inacceptably slow for large > mailboxes if reverse_alias is enabled, and if there is even a modest > number of aliases in place (here: 500). The main culprit is the > reverse alias lookup code which does a linear search through a > linked list. That code is invoked each time an address is made > "human-friendly", i.e., *often*. > > It also looks like the IDNA code is invoked way more often than it > should be, and like we're juggling around with dynamic memory where > it isn't worth it. > > The attached patch does several things: > > - reverse alias lookup is fixed to be hash-based. I haven't > bothered to fix the forward alias lookups, since these are > invoked on a much smaller scale > > - perform a check for IDN-ness, and cache the result, before > subjecting an address to the larger IDN code just for display > purposes > > - throw away some oft he dynamic memory wastefulness in > compare_from and compare_to; cut off comparison after 128 > characters. > > Brendan, I haven't pushed this into HG quite yet. This reads fine to me. I'm not sure I'm crazy about the SHORT_STRING change in compare_* though - it'd be nicer if we could just do fewer comparisons. I grant that we use fixed-length buffers all over the place. Some day maybe we should think about keeping a buffer pool around :) Do you have any idea how much time the alloc/free stuff in compare_foo is burning?
Attachment:
pgpgxshY5mLT7.pgp
Description: PGP signature