Gnus development mailing list
 help / color / mirror / Atom feed
From: David Moore <dmoore@UCSD.EDU>
Subject: Re: The A A command takes forever to complete
Date: 22 Nov 1996 21:22:36 -0800	[thread overview]
Message-ID: <rvybftcrmr.fsf@sdnp5.ucsd.edu> (raw)
In-Reply-To: Lars Magne Ingebrigtsen's message of 23 Nov 1996 04:58:07 +0100

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> David Moore <dmoore@UCSD.EDU> writes:
> 
> > 	The same bug occurs with 'Y c' in the summary buffer.  So I
> > recommend never hitting 'Y c' unless you only have less than about 10
> > cached articles.  It takes about 8 minutes to insert 145 cached articles
> > into the summary buffer on my machine. ;)  So, it's usually faster just
> > to hit 'C-u Z R'.
> 
> Yup.  Commands like `Y c' (and `^') rebuild threads, which means that
> they have to do all kinds of things to work properly.  I'm sure they
> do too much -- that part of the code is a wilderness I've yet to
> tame. 

	I seem to recall my profiling showing the thread stuff being
reasonable, and that all of the time was spent doing text-property-any's
and inserting the line.  Similar to the costs for
gnus-group-update-group which still hits nnvirtual harder than it
should.  And also hurts when you do an 'l' in the group buffer on a line
which will not be shown after that display.  

> Perhaps `Y c' should just do a complete regeneration of the summary
> buffer once if there's more than a couple of articles to be
> inserted...  Either that, or we'll have to rewrite the general summary
> buffer thread regeneration code.  Which might be a good idea.

	'Y c' could do the complete regeneration which would help with
the summary buffer, but I don't think rewriting the thread code will
help much (although it might speed it up a slight bit, I didn't save
traces of it, since it didn't seem to be the big cost).

	At the moment I'm looking into a data-structure to replace the
need for the text properties in the group buffer, which allows very
quick inserts and the appropriate movement searchs.  Hopefully the
approach will be general enough to work with the summary buffer as well.

-- 
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!


  reply	other threads:[~1996-11-23  5:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-11-22 16:15 Magnus Hammerin
1996-11-22 18:27 ` David Moore
1996-11-23  3:58   ` Lars Magne Ingebrigtsen
1996-11-23  5:22     ` David Moore [this message]
1996-11-23 19:35       ` Lars Magne Ingebrigtsen
1996-11-23 19:58       ` 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=rvybftcrmr.fsf@sdnp5.ucsd.edu \
    --to=dmoore@ucsd.edu \
    /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).