Andrew Cohen <acohen@ust.hk> writes:


This latency could well be gmail specific --- perhaps nnselect is doing
something in "catchup" that is heavy-weight with respect to gmail/imap
integration (note: I'm just fishing here).

>>>>>> "TVR" == T V Raman <raman@google.com> writes:
>
>     TVR> Andrew Cohen <acohen@ust.hk> writes: I first noticed it after
>     TVR> search broke for me and was restored.
>
> OK, going back through your messages it appears that this was Nov 7, and
> you were pretty clearly using the nnselect backend prior to that.  This
> would tend to point the finger at gnus-search.
>
> But I'm kind of stumped how it could be gnus-search, since it should by
> completely out of the loop once the list of articles is generated. This
> suggests that something else (neither nnselect or gnus-search) changed
> coincidentally around the same time. I don't see anything obvious in the
> git logs from around this time. 
>
> I wish I could reproduce it. Just as a benchmark I do a search with an
> imap group with about 20,000 messages that returns 4000 search hits. It
> takes well under 1s from hitting "q" to finishing back at the group
> buffer. (I haven't done better timing since I am assuming your observed
> latency is more than this). 
>
> Some questions:
>
> The symptoms are: you enter a search group, do whatever, hit "q" to
> exit, and it just takes awhile before you are back in the group buffer? 
>
> I assume this is with an ephemeral search group? (If it is a permanent
> group things might be different).
>
> Do you use the registry? If so does turning it off eliminate the latency?
>
>
>
>
>

-- 

Thanks,

--Raman
♈ Id: kg:/m/0285kf1  🦮