Re: wanderlust is sooo slooowww...

[Ken Gunderson <kgunders@teamcool.net>]

At Mon, 27 Oct 2014 22:42:21 -0700,
Erik Hetzner wrote:
> 
> At Mon, 27 Oct 2014 14:03:47 -0600,
> Ken Gunderson wrote:
> > 
> > 
> > Elmo debug.  Geronimo, here ya' go...
> > 
> > Erik's e6h stuff:
> 
> Thank you, Ken, this was a very clean and well-edited IMAP debug log.

You're welcome.  I edited out most folders and only used 1 account.
In reality, I have several accounts with numerous subfolders
containing thousands of messages.

> The core of this problem seems to be that we are sending a command
> that is too long to the cyrus IMAP server. This is documented here:
> 
>   http://comments.gmane.org/gmane.mail.imap.cyrus/30061

So if I read this correctly (and it's getting late here...) there is a
problem when token or quoted string is longer than 8K bytes.

So why would essentially same search trigger this in recent versions of WL
but not earlier?

> If you have control of the server, the easiest thing might be to
> increase this compile time setting. A workaround might be to add a
> test in elmo-imap4-search-mergeable-p to ensure that long searches are
> not merged into even longer searches. Here is a new version of this
> function that you might try and report back on:
> 
> (defun elmo-imap4-search-mergeable-p (a b)
>   "Return t if A and B are two mergeable IMAP searches.
> 
> A is the result of a call to elmo-imap4-search-generate.
> B is the result of a call to elmo-imap4-search-generate."
>   (let ((cara (car a))
> 	(carb (car b))
>         (toobig nil)
>         (check-length (lambda (s)
>                         (if (and (stringp s)
>                                  (> (length s) 4000))
>                             (setq toobig t)))))
>     (mapc check-length a)
>     (mapc check-length b)
>     (and (not toobig)
>          (not (numberp cara))
> 	 (not (numberp carb))
> 	 (or (null cara)
> 	     (null carb)
> 	     (equal cara carb)))))
> 
> I’m not too happy with this solution, but I’m not sure what other
> options there are in this case. The best solution (I think) would be
> to contact your server administrators and ask them to increase this
> buffer size.
> 
> best, Erik

Re: server side compile setting.  Maybe.  But we've yet to address why
WL has also become soooo sloooooow.  Do you think this 8K thing could
also explain that?  Seems unlikely.  Do WL devs have any ideas about
what changed WL side that triggered these issues?

Re: workaround.  Have to get some sleep first.

Best--  Ken