Gnus development mailing list
 help / color / mirror / Atom feed
* (gnus-summary-goto-article <message-id>) extremely slow for certain IMAP server
@ 2010-07-26 18:42 Tassilo Horn
  2010-07-26 19:27 ` David Engster
  0 siblings, 1 reply; 6+ messages in thread
From: Tassilo Horn @ 2010-07-26 18:42 UTC (permalink / raw)
  To: ding; +Cc: Sébastien Vauban, David Maus

Hi all,

I maintain Org-mode's org-gnus.el, which allows linking to Gnus articles
in Org-mode.  Links to articles are stored by their group and their
message-id.  When following a link a call like

  (gnus-summary-goto-article <message-id>)

will be done.  Unfortunately, for Sébastien (in Cc) this call to a
message on some IMAP server takes ages for bigger groups (~5 minutes).

We've edebugged and profiled the gnus code, and the culprit is the
function `nnimap-request-article-part'.  When given a message-id instead
of an article number, that function will query the IMAP server with
`imap-search', and then emacs hangs 5 minutes till the server finally
responds.

Ok, it's basically the server's fault, but can't Gnus do any better?
Especially, the mapping message-id to article number is also contained
in the .overview file of the group, but it seems that this file is not
checked.

Or can this call to `imap-search' somehow be omitted by optional Gnus
features like the gnus registry?

You can check the full Org-mode thread with the report and all debugging
details at

  http://thread.gmane.org/gmane.emacs.orgmode/26722/focus=27590

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: (gnus-summary-goto-article <message-id>) extremely slow for certain IMAP server
  2010-07-26 18:42 (gnus-summary-goto-article <message-id>) extremely slow for certain IMAP server Tassilo Horn
@ 2010-07-26 19:27 ` David Engster
  2010-07-26 19:43   ` Tassilo Horn
  0 siblings, 1 reply; 6+ messages in thread
From: David Engster @ 2010-07-26 19:27 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: ding, Sébastien Vauban, David Maus

Tassilo Horn writes:
> We've edebugged and profiled the gnus code, and the culprit is the
> function `nnimap-request-article-part'.  When given a message-id instead
> of an article number, that function will query the IMAP server with
> `imap-search', and then emacs hangs 5 minutes till the server finally
> responds.
>
> Ok, it's basically the server's fault, 

Yes. An IMAP server should be able to retrieve articles based on
message-id's very quickly, since this is a pretty common task.

> but can't Gnus do any better?  Especially, the mapping message-id to
> article number is also contained in the .overview file of the group,
> but it seems that this file is not checked.

Yes. You could use nnimap-retrieve-headers-from-file and check if you
find the MID there.

> Or can this call to `imap-search' somehow be omitted by optional Gnus
> features like the gnus registry?

Probably, but currently the registry does not keep track of the article
numbers, only of the groups. I guess this could easily be added, though?

But why don't you just save the article number together with the
message-id in the link?

-David



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: (gnus-summary-goto-article <message-id>) extremely slow for certain IMAP server
  2010-07-26 19:27 ` David Engster
@ 2010-07-26 19:43   ` Tassilo Horn
  2010-07-26 20:29     ` David Engster
  2010-07-26 21:08     ` Ted Zlatanov
  0 siblings, 2 replies; 6+ messages in thread
From: Tassilo Horn @ 2010-07-26 19:43 UTC (permalink / raw)
  To: David Engster; +Cc: ding, Sébastien Vauban, David Maus

On Monday 26 July 2010 21:27:13 David Engster wrote:

> > We've edebugged and profiled the gnus code, and the culprit is the
> > function `nnimap-request-article-part'.  When given a message-id instead
> > of an article number, that function will query the IMAP server with
> > `imap-search', and then emacs hangs 5 minutes till the server finally
> > responds.
> >
> > Ok, it's basically the server's fault, 
> 
> Yes. An IMAP server should be able to retrieve articles based on
> message-id's very quickly, since this is a pretty common task.

That's my impression, too.  But at least Sébastiens Courier server seems
to think otherwise.  Maybe it's only some config option the admins need
to enable, who knows...

> > but can't Gnus do any better?  Especially, the mapping message-id to
> > article number is also contained in the .overview file of the group,
> > but it seems that this file is not checked.
> 
> Yes. You could use nnimap-retrieve-headers-from-file and check if you
> find the MID there.

Hm, ok.  How do I get server for a given nnimap+Foo:some.group spec?
`gnus-group-server'?

> > Or can this call to `imap-search' somehow be omitted by optional
> > Gnus features like the gnus registry?
> 
> Probably, but currently the registry does not keep track of the
> article numbers, only of the groups. I guess this could easily be
> added, though?
> 
> But why don't you just save the article number together with the
> message-id in the link?

Because article numbers can change on editable backends, for examply by
moving mail back and forth to other groups.

Bye,
Tassilo



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: (gnus-summary-goto-article <message-id>) extremely slow for certain IMAP server
  2010-07-26 19:43   ` Tassilo Horn
@ 2010-07-26 20:29     ` David Engster
  2010-07-26 21:08     ` Ted Zlatanov
  1 sibling, 0 replies; 6+ messages in thread
From: David Engster @ 2010-07-26 20:29 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: ding, Sébastien Vauban, David Maus

Tassilo Horn writes:
>> Yes. You could use nnimap-retrieve-headers-from-file and check if you
>> find the MID there.
>
> Hm, ok.  How do I get server for a given nnimap+Foo:some.group spec?
> `gnus-group-server'?

Well, that depends... In any case, the nnimap- functions don't accept
the 'nnimap:' prefix.

I think the safest way is to make a detour over the group's method:

(nth 1 (gnus-find-method-for-group group))

That may be costly, but otherwise you have to fiddle with the different
naming conventions of primary, secondary and foreign groups. And you
don't want that.

-David



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: (gnus-summary-goto-article <message-id>) extremely slow for certain IMAP server
  2010-07-26 19:43   ` Tassilo Horn
  2010-07-26 20:29     ` David Engster
@ 2010-07-26 21:08     ` Ted Zlatanov
  2010-07-26 21:29       ` David Engster
  1 sibling, 1 reply; 6+ messages in thread
From: Ted Zlatanov @ 2010-07-26 21:08 UTC (permalink / raw)
  To: ding

On Mon, 26 Jul 2010 21:43:02 +0200 Tassilo Horn <tassilo@member.fsf.org> wrote: 

TH> On Monday 26 July 2010 21:27:13 David Engster wrote:

>> Yes. An IMAP server should be able to retrieve articles based on
>> message-id's very quickly, since this is a pretty common task.

TH> That's my impression, too.  But at least Sébastiens Courier server seems
TH> to think otherwise.  Maybe it's only some config option the admins need
TH> to enable, who knows...

I use Courier and it's pretty fast for message-id searches.  Perhaps
Sébastien can run a local IMAP synced server?

>> > Or can this call to `imap-search' somehow be omitted by optional
>> > Gnus features like the gnus registry?
>> 
>> Probably, but currently the registry does not keep track of the
>> article numbers, only of the groups. I guess this could easily be
>> added, though?

Yes, but it wouldn't help for IMAP.  IMAP article numbers are too
mutable.  The registry tries to be above the backend level and article
numbers are too close to that level.  But it's not hard at all to add
extra data of any type; see gnus-registry-fetch-extra-entry and
gnus-registry-store-extra-entry.  The registry marks use those functions.

On Mon, 26 Jul 2010 22:29:12 +0200 David Engster <deng@randomsample.de> wrote: 

DE> (nth 1 (gnus-find-method-for-group group))

I think (gnus-method-to-server-name (gnus-find-method-for-group group))
is a little better.

Ted




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: (gnus-summary-goto-article <message-id>) extremely slow for certain IMAP server
  2010-07-26 21:08     ` Ted Zlatanov
@ 2010-07-26 21:29       ` David Engster
  0 siblings, 0 replies; 6+ messages in thread
From: David Engster @ 2010-07-26 21:29 UTC (permalink / raw)
  To: ding

Ted Zlatanov writes:
> TH> On Monday 26 July 2010 21:27:13 David Engster wrote:
>>> Probably, but currently the registry does not keep track of the
>>> article numbers, only of the groups. I guess this could easily be
>>> added, though?
>
> Yes, but it wouldn't help for IMAP.  IMAP article numbers are too
> mutable.

I think it could help in many cases, since article numbers should be
pretty fixed as long as people don't respool (and I guess that the
registry could even deal with that since it's in the copy/move
hooks). 

But I agree that it is better to keep the registry out of the backend
business. :-)

> The registry tries to be above the backend level and article
> numbers are too close to that level.  But it's not hard at all to add
> extra data of any type; see gnus-registry-fetch-extra-entry and
> gnus-registry-store-extra-entry.  The registry marks use those functions.
>
> On Mon, 26 Jul 2010 22:29:12 +0200 David Engster <deng@randomsample.de> wrote: 
>
> DE> (nth 1 (gnus-find-method-for-group group))
>
> I think (gnus-method-to-server-name (gnus-find-method-for-group group))
> is a little better.

This will get you a fully qualified name with the nnimap+ prefix, which
you'd then have to remove again for the nnimap backend functions.

-David



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-07-26 21:29 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-26 18:42 (gnus-summary-goto-article <message-id>) extremely slow for certain IMAP server Tassilo Horn
2010-07-26 19:27 ` David Engster
2010-07-26 19:43   ` Tassilo Horn
2010-07-26 20:29     ` David Engster
2010-07-26 21:08     ` Ted Zlatanov
2010-07-26 21:29       ` David Engster

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).