[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gnus-summary: sorting after / s restriction takes unexpectedly long
From: |
Daniel Ortmann |
Subject: |
gnus-summary: sorting after / s restriction takes unexpectedly long |
Date: |
18 Nov 2001 12:25:23 -0600 |
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.
Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.
In GNU Emacs 21.1.1 (i386--freebsd, X toolkit, Xaw3d scroll bars)
of 2001-11-09 on pyrl.eye
configured using `configure --prefix=/usr/local i386--freebsd'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
locale-coding-system: nil
default-enable-multibyte-characters: t
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
The behavior being described has existed in emacs gnus for quite
awhile. I am reporting it now since I realize it is probably something
that could use fixing.
Gnus Problem:
Sorting a gnus-summary buffer of (say) 4000 entries takes an
expectedly long amount of time. After performing one of the
gnus-summary-limit-* functions such as gnus-summary-limit-to-subject
(invoked by [?/ ?s] in the summary buffer) to limit the lines about
40-50, the sorting is _still_ long, unexpectedly long.
My Expectation:
I expected that sorting on the restricted buffer would be much
faster than on the entire buffer.
My Speculation:
Perhaps sorting in a restricted summary buffer is still being
performed on the _entire_ buffer contents rather than on the subset?
I had imagined that each restriction/limit request would produce
some type of sub-list with entries pointing back to the real summary
lines; then sorting the sub-list should be fast automatically.
Steps To Repeat:
1) Start emacs, gnus, and select any large newsgroup by pressing
4000 <enter> in the article selection buffer. (The size of the
individual articles does not matter since we will only be working
in the gnus-summary buffer.)
2) Note the time it takes to sort by subject when you press
C-c C-s C-s
3) Pick a phrase that exists in 10-50 subjects and perform a filter
action using gnus-summary-limit-to-subject by pressing / s,
typing in the phrase and pressing <enter>.
4) Now note the time it takes to re-sort the buffer, perhaps by
subject as before, perhaps by date using C-c C-s C-d, or by # of
lines with C-c C-s C-l.
The Result:
The time it takes to sort the buffer is unexpectedly long.
Recent input:
M-x r e p o r t - e m a c s TAB RET
Recent messages:
Loading image...done
Loading time...done
Loading /usr/local/libexec/emacs/21.1/i386--freebsd/fns-21.1.1.el
(source)...done
Loading font-lock...
Loading regexp-opt...done
Loading font-lock...done
Loading jka-compr...done
Loading server...done
Loading hscroll...done
Loading emacsbug...done
--
Daniel Ortmann, 2414 30 Av NW, #D, Rochester, MN 55901
ortmann@isl.net (h) / 507.288.7732 (h)
dortmann@lsil.com (w) / 507.529.3887 (w)
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- gnus-summary: sorting after / s restriction takes unexpectedly long,
Daniel Ortmann <=