speedup in gnus-sum (B m command)

speedup in gnus-sum (B m command)

[David Moore]

	It always seemed strange to me that 'B m' would take 10-20
seconds before it even prompted me for the destination group name.
With this replacement gnus-read-move-group-name in my .gnus, even when
uncompiled I get the prompt in 0 time, and it seems equivalently fast
for doing expansion.


	I'm also currently putzing around with changes to elp which
allow it to do full profiling (ie, call tree information) which might
help with gnus's strange oo-backend call traces.  Before I write all of
this, has anyone on the list done something similar?  (I've already
fixed elp to properly handle autoloads and keysequences making it
"safer" to use on gnus.)


;;; dmoore@ucsd.edu 26.10.96
;;; gnus-read-move-group-name was horribly expensive.  Fixed up.
;;; Avoid calling mapatoms on possible huge gnus-active-hashtb,
;;; and rather let completing read do what it was designed to.


(defun gnus-valid-move-group-p (group)
  (and (boundp group)
       (symbol-name group)
       (memq 'respool
	     (assoc (symbol-name
		     (car (gnus-find-method-for-group
			   (symbol-name group))))
		    gnus-valid-select-methods))))

(defun gnus-read-move-group-name (prompt default articles prefix)
  "Read a group name."
  (let* ((split-name (gnus-get-split-value gnus-move-split-methods))
	 (minibuffer-confirm-incomplete nil) ; XEmacs
	 (prom
	  (format "%s %s to:"
		  prompt
		  (if (> (length articles) 1)
		      (format "these %d articles" (length articles))
		    "this article")))
	 (to-newsgroup
	  (cond
	   ((null split-name)
	    (gnus-completing-read default prom
				  gnus-active-hashtb
				  'gnus-valid-move-group-p
				  nil prefix
				  'gnus-group-history))
	   ((= 1 (length split-name))
	    (gnus-completing-read (car split-name) prom
				  gnus-active-hashtb
				  'gnus-valid-move-group-p
				  nil nil
				  'gnus-group-history))
	   (t
	    (gnus-completing-read nil prom 
				  (mapcar (lambda (el) (list el))
					  (nreverse split-name))
				  nil nil nil
				  'gnus-group-history)))))
    (when to-newsgroup
      (if (or (string= to-newsgroup "")
	      (string= to-newsgroup prefix))
	  (setq to-newsgroup (or default "")))
      (or (gnus-active to-newsgroup)
	  (gnus-activate-group to-newsgroup)
	  (if (gnus-y-or-n-p (format "No such group: %s.  Create it? "
				     to-newsgroup))
	      (or (and (gnus-request-create-group 
			to-newsgroup (gnus-group-name-to-method to-newsgroup))
		       (gnus-activate-group to-newsgroup nil nil
					    (gnus-group-name-to-method
					     to-newsgroup)))
		  (error "Couldn't create group %s" to-newsgroup)))
	  (error "No such group: %s" to-newsgroup)))
    to-newsgroup))

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

ELP (was Re: speedup in gnus-sum (B m command))

[Ken Raeburn]

David Moore <dmoore@UCSD.EDU> writes:

> 	I'm also currently putzing around with changes to elp which
> allow it to do full profiling (ie, call tree information) which might
> help with gnus's strange oo-backend call traces.  Before I write all of
> this, has anyone on the list done something similar?  (I've already
> fixed elp to properly handle autoloads and keysequences making it
> "safer" to use on gnus.)

Great!  I recently asked the same question in bug-gnu-emacs, and the
answer appears to be "no", but I don't have the time to do the actual
work right now.

Some bits of information I got from the maintainer:

 * the correct email address for correspondence is tools-help@python.org,
   not the address used by M-x elp-submit-bug-report
 * the maintainer is "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
   but you should use the above email address, and he's got "little
   incentive (or time)" to work on this idea, but would welcome the
   contribution of code
 * a newer version of elp than either emacs-19.34 or xemacs has,
   version 2.37, is available, at http://www.python.org/ftp/emacs/;
   it has mostly bug fixes, some small new features; it's been
   submitted to rms too for future releases

Ken