From: "T.V Raman" <raman@google.com>
To: Andrew Cohen <acohen@ust.hk>
Cc: emacs-devel@gnu.org
Subject: Re: NNSelect Failing
Date: Sat, 19 Dec 2020 07:08:59 -0800 [thread overview]
Message-ID: <p91y2ht3kac.fsf@google.com> (raw)
In-Reply-To: <87o8iqh7c6.fsf@ust.hk> (Andrew Cohen's message of "Sat, 19 Dec 2020 10:12:41 +0800")
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1731 bytes --]
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
7©4 Id: kg:/m/0285kf1 0Ü8
next prev parent reply other threads:[~2020-12-19 15:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 16:41 NNSelect Failing T.V Raman
2020-12-17 16:57 ` Eric Abrahamsen
2020-12-17 20:57 ` T.V Raman
2020-12-17 20:59 ` T.V Raman
2020-12-17 21:05 ` Eric Abrahamsen
2020-12-17 21:18 ` T.V Raman via Emacs development discussions.
2020-12-17 22:19 ` Eric Abrahamsen
2020-12-18 1:42 ` T.V Raman
2020-12-18 3:44 ` Eric Abrahamsen
2020-12-18 15:40 ` T.V Raman
2020-12-18 15:58 ` T.V Raman
2020-12-18 16:04 ` T.V Raman
2020-12-18 17:44 ` Eric Abrahamsen
2020-12-18 18:50 ` T.V Raman
2020-12-18 20:03 ` Eric Abrahamsen
2020-12-19 0:03 ` Andrew Cohen
2020-12-19 1:44 ` T.V Raman
2020-12-19 2:12 ` Andrew Cohen
2020-12-19 15:08 ` T.V Raman [this message]
2020-12-18 17:40 ` Eric Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=p91y2ht3kac.fsf@google.com \
--to=raman@google.com \
--cc=acohen@ust.hk \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.