Gnus development mailing list
 help / color / mirror / Atom feed
From: Steinar Bang <sb@dod.no>
To: ding@gnus.org
Subject: Re: Anyone ever used gnus-change-server?
Date: Mon, 08 Feb 2010 18:40:22 +0100	[thread overview]
Message-ID: <878wb3k4mx.fsf@edwards.hjemme.lan> (raw)
In-Reply-To: <87d40klohp.fsf@edwards.hjemme.lan>

I've done a little edebug'ing and this is what I found out:

 - I did edebug-defun on gnus-move-group-to-server
 - I ran `M-x gnus-change-server RET'
 - On each stop in gnus-move-group-to-server I did `c', until it
   eventually got stuck in moving no.alt.motorsykler with 33523 articles
   seen.  Here are the first lines of the edebug-trace (it's too big to
   include all of it):
    { gnus-move-group-to-server args: ((dummy.group 0 nil) (nntp news) (nn
    } gnus-move-group-to-server result: Translating dummy.group...done    
    { gnus-move-group-to-server args: ((no.test 6 ((1 . 952) (3258 . 3283)
    } gnus-move-group-to-server result: Translating no.test...done        
    { gnus-move-group-to-server args: ((no.sport.motorsport 3 ((1 . 44) 52
    } gnus-move-group-to-server result: Translating no.sport.motorsport...
    { gnus-move-group-to-server args: ((no.alt.motorsykler 3 ((1 . 33523))
 - I left it running for a day or so, and then C-g'd it
 - Then I stepped through some iterations with `n'.  It was spending its
   time in this loop:
	  (while (looking-at
		  "^[0-9]+\t[^\t]*\t[^\t]*\t[^\t]*\t\\([^\t]*\\)\t")
	    (when (setq to-article
			(gnus-gethash
			 (buffer-substring (match-beginning 1) (match-end 1))
			 hashtb))
	      ;; Add this article to the list of read articles.
	      (push to-article to-reads)
	      ;; See if there are any marks and then add them.
	      (when (setq mark (assq (read (current-buffer)) marks))
		(setq marks (delq mark marks))
		(setcar mark to-article)
		(push mark to-marks))
	      (forward-line 1)))
   The test in the while returned t for all of the steppings I did, and
   the cond in the when returned nil for all steppings I did.
   Not really a surprising result if we're talking about 60 ticked
   articles of a total of 33000 or thereabouts

I'm guessing this while loop is where it has spent its time.

So I guess the move-server methods really take too much time to be of
use.  At least if the available article count is too large (with a 14
day expiry, they probably would have worked ok).




  reply	other threads:[~2010-02-08 17:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-03 11:24 Steinar Bang
2010-02-03 17:50 ` Steinar Bang
2010-02-04 15:54   ` Steinar Bang
2010-02-04 20:44     ` Steinar Bang
2010-02-08 17:40       ` Steinar Bang [this message]
2010-08-29 17:15         ` Lars Magne Ingebrigtsen

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=878wb3k4mx.fsf@edwards.hjemme.lan \
    --to=sb@dod.no \
    --cc=ding@gnus.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.
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).