Re: Behavior of Gnus when called from an hyperlink

From: "Sébastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: Behavior of Gnus when called from an hyperlink
Date: Sat, 17 Jul 2010 21:59:38 +0200	[thread overview]
Message-ID: <87zkxpanh1.fsf@mundaneum.com> (raw)
In-Reply-To: 13292.1279382554@gamaville.dokosmarshall.org

Hi Nick and Tassilo,

Nick Dokos wrote:
> Tassilo Horn <tassilo-IGUgQLVVQiRCV4ILt04nZQ@public.gmane.org> wrote:
>> Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> 
>>> If I understand well, it wasted all the time evaluating
>>>
>>> --8<---------------cut here---------------start------------->8---
>>>     (nth 1 gnus-command-method)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> I can't understand anything from the above... Someone does?
>>
>> Not really. Picking the second element out of a list must not take 5
>> minutes! What's the value of `gnus-command-method' when this happens? One
>> SPC before the hang, that variable is evaluated and its contents are
>> printed to *Messages*.
>
> try single stepping to that point and evaluate the various expressions
> that enter into the computation. For example,
>
>>>      ;; Use `head' function.
>>>      ((fboundp head)
>>>       (setq res (funcall head article (gnus-group-real-name group)
>>>   ->                     (nth 1 gnus-command-method))))
>
> put the cursor after the closing paren of the (nth 1 gnus-command-method)
> form and type C-x C-e, after the closing paren of (gnus-group-real-name
> group) and do the same and after the closing paren of the (funcall ...) and
> do the same. Also perhaps after the head variable (between head and article)
> and do the same. Tassilo is right of course that (nth 1 gnus-command-method)
> should be trivial (unless nth has been redefined somehow and is trying to
> prove the Riemann hypothesis instead :-) ) -- but the cursor might be off by
> one and it's really the funcall that's taking all the time.

By carefully reading the article just sent by Erik (in another thread) about
Edebug, becoming aware of the cursor movements under stepping, I now can say
without error what *really* eats the time.

I effectively saw every parameter evaluated, every one after the other. Here
are the results:

- head :: nnimap-request-head
- article :: "<871vbxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org>"
- (gnus-group-real-name group) :: "INBOX.mc"
- gnus-command-method :: (nnimap "mc"
                              (nnimap-address "mail.missioncriticalit.com")
                              (nnir-search-engine imap))
- (nth 1 gnus-command-method) :: "mc"
- (funcall nnimap-request-head "<871vbxzo6.fsf-pwAqS3aGAJQybS5Ee8rs3A@public.gmane.org>" "INBOX.mc" "mc")
  results... after 5 mins... in ("INBOX.mc" . 28606)

So, that's not `nth' that took the time (as previously thought), but the
`funcall'.

What does the jury thinks of that?

Thanks a lot for your remote assistance!
  Seb

-- 
Sébastien Vauban

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode