Gnus as slow as molasses

Gnus as slow as molasses

[Eze Ogwuma]

Hi,

I'm using Gnus for mail reading with nnml and I find that when I enter 
a group with a large (over 5000) number of articles in it (read or
unread) Gnus takes up to 15 seconds to show the first article
selected. After that all the other articles are shown quickly.

This occurs even if I enter the summary buffer with only some of the
articles visible.

Has anyone else noticed this?
-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Eze Ogwuma]

Eze Ogwuma <typhoon@dircon.co.uk> writes:

> Hi,
> 
> I'm using Gnus for mail reading with nnml and I find that when I enter 
> a group with a large (over 5000) number of articles in it (read or
> unread) Gnus takes up to 15 seconds to show the first article
> selected. After that all the other articles are shown quickly.
> 
> This occurs even if I enter the summary buffer with only some of the
> articles visible.
> 
> Has anyone else noticed this?

This additional information was sent to someone as a reply.

The problem isn't opening the group as I rarely select more that 100
articles. It's selecting the first article once I'm in the group.

I have this in my .gnus file so I get to choose which article to
select:
;; Don't select the first article automatically
(setq  gnus-auto-select-first nil)   

Whichever article I select then takes about 10-15 seconds to
display. All articles selected after that are almost instantaneous
whether they are above or below the first article.

-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Kai Grossjohann]

Eze Ogwuma <typhoon@dircon.co.uk> writes:

  > The problem isn't opening the group as I rarely select more that 100
  > articles. It's selecting the first article once I'm in the group.

Amazing.  I could understand that it takes a while to fetch the
headers (if you have fetch old headers set to t, Gnus will fetch all
headers even if you do 1 RET on a group).  But apparently, fetching
headers is fast for you, as is displaying the summary buffer.  Only
when hitting RET or SPC or mouse-2 on an article, that takes so long,
right?

Is your ~/Mail accessed via NFS by your Gnus?  Or.  Hm.  Wait a
minute.  Are you using nnfolder?  Maybe Gnus needs to load the whole
group into memory as one file in order to display the first article?

kai
-- 
Really cancel?   [OK]  [Cancel]

Re: Gnus as slow as molasses

[Hrvoje Niksic]

Eze Ogwuma <typhoon@dircon.co.uk> writes:

> This additional information was sent to someone as a reply.
> 
> The problem isn't opening the group as I rarely select more that 100
> articles. It's selecting the first article once I'm in the group.
> 
> I have this in my .gnus file so I get to choose which article to
> select:
> ;; Don't select the first article automatically
> (setq  gnus-auto-select-first nil)   
> 
> Whichever article I select then takes about 10-15 seconds to
> display. All articles selected after that are almost instantaneous
> whether they are above or below the first article.

Under XEmacs 20.4 you can use `M-x profile-key-sequence', press a key
(say RET in the Group buffer), and get the results using
`M-x profile-results'.  It should give you an idea of where the time
is being spent.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The end of the world is coming...  SAVE YOUR BUFFERS!

Re: Gnus as slow as molasses

[Eze Ogwuma]

Kai Grossjohann <grossjohann@charly.cs.uni-dortmund.de> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> 
>   > The problem isn't opening the group as I rarely select more that 100
>   > articles. It's selecting the first article once I'm in the group.
> 
> Amazing.  I could understand that it takes a while to fetch the
> headers (if you have fetch old headers set to t, Gnus will fetch all
> headers even if you do 1 RET on a group).  But apparently, fetching
> headers is fast for you, as is displaying the summary buffer.  Only
> when hitting RET or SPC or mouse-2 on an article, that takes so long,
> right?

Yes. But the second article selected is "fast" whether it is above or
below the first selected article..

> Is your ~/Mail accessed via NFS by your Gnus?  

No.

> Or.  Hm.  Wait a
> minute.  Are you using nnfolder?  Maybe Gnus needs to load the whole
> group into memory as one file in order to display the first article?

I'm using nnml so I didn't think it would have to do this. There's
something it does when the first article is selected in a new Summary
buffer. See my reply to Hrvoje Niksic for profiling results.

Thanks.
-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Eze Ogwuma]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> 
> > This additional information was sent to someone as a reply.
> > 
> > The problem isn't opening the group as I rarely select more that 100
> > articles. It's selecting the first article once I'm in the group.
> > 
> > I have this in my .gnus file so I get to choose which article to
> > select:
> > ;; Don't select the first article automatically
> > (setq  gnus-auto-select-first nil)   
> > 
> > Whichever article I select then takes about 10-15 seconds to
> > display. All articles selected after that are almost instantaneous
> > whether they are above or below the first article.
> 
> Under XEmacs 20.4 you can use `M-x profile-key-sequence', press a key
> (say RET in the Group buffer), and get the results using
> `M-x profile-results'.  It should give you an idea of where the time
> is being spent.

Thanks, I was hoping for something like this. The results are below.

I think this has something to do with the number of read/unread
articles in a group. For some reason, before showing the first
article, Gnus parses the article directory twice. There is an strace
of some "open" calls at the very end of this message.

1) Gnus thinks one group has ~17600 articles in it with ~7800
unread. It takes around 15-18 seconds to open the first article even
when the Summary buffer only has 100 articles in it.

2) A buffer with ~9000 articles of which ~500 are unread takes about
8-11 seconds to select the first article.

3) A buffer with ~3000 articles of which ~2300 are unread takes about
3 seconds to select the first article.

4) A buffer with ~1800 articles of which 16 are unread takes less than
1 second to select the first article.

The profiles are for cases 1 and 4.

I use the article backlog and this works in all buffers. I've found
that exiting a buffer then re-entering and selecting a previously seen
article (already in the backlog) is instantaneous. While exiting a
buffer then re-entering and selecting a previously unseen article takes 
the same time as normal.

These problems all occur with no .gnus file and only a pointer to my
Gnus lisp directories in my .emacs file.



********* Profiles *********

SLOW


Function Name                              Ticks    %/Total
=======================================    =====    =======
(in garbage collection)                    303      20.254
string-match                               264      17.647
directory-files                            261      17.447
match-string                               168      11.230
#<compiled-function (from "nnheader.elc") (file) "...(27)" [file nnheader-numerical-short-files ^[0-9]+$ string-to-int string-match match-string 0] 4>    162      10.829
string-to-int                              50       3.342 
put-char-table                             46       3.075 
syntax-string-to-code                      25       1.671 
load-internal                              16       1.070 
put-text-property                          14       0.936 
re-search-forward                          14       0.936 
modify-syntax-entry                        13       0.869 
insert-buffer-substring                    12       0.802 
next-single-property-change                11       0.735 
mapcar                                     11       0.735 
x-get-resource                             11       0.735 
check-menu-syntax                          9        0.602 
text-prop-extent-paste-function            6        0.401 
simple-set-syntax-entry                    6        0.401 
#<compiled-function (from "mail-extr.elc") (item) "...(49)" [item 2 modify-syntax-entry syntax-table syntax bound char] 5>    5        0.334 
x-init-face-from-resources                 5        0.334 
add-text-properties                        4        0.267 
init-face-from-resources                   4        0.267 
logior                                     4        0.267 
char-to-string                             4        0.267 
#<compiled-function (from "mail-extr.elc") (x) "...(28)" [put intern x ob domain-name 2 format] 6>    3        0.201 
x-get-resource-and-maybe-bogosity-check    3        0.201 
x-bogosity-check-resource                  3        0.201 
make-extent                                2        0.134 
looking-at                                 2        0.134 
file-exists-p                              2        0.134 
syntax-table-p                             2        0.134 
kill-all-local-variables                   2        0.134 
custom-initialize-reset                    2        0.134 
custom-add-to-group                        2        0.134 
lsh                                        2        0.134 
format                                     2        0.134 
copy-keymap                                1        0.067 
nnheader-directory-files-safe              1        0.067 
nnheader-replace-chars-in-string           1        0.067 
gnus-add-text-properties                   1        0.067 
gnus-put-text-property                     1        0.067 
eval                                       1        0.067 
run-hook-with-args                         1        0.067 
buffer-substring-no-properties             1        0.067 
gnus-xmas-redefine                         1        0.067 
gnus-cite-add-face                         1        0.067 
gnus-article-hide-headers-if-wanted        1        0.067 
gnus-article-add-buttons-to-head           1        0.067 
gnus-article-highlight-headers             1        0.067 
set-extent-face                            1        0.067 
redisplay-echo-area                        1        0.067 
get-text-property                          1        0.067 
store-match-data                           1        0.067 
get-face                                   1        0.067 
face-name                                  1        0.067 
valid-instantiator-p                       1        0.067 
try-font-name                              1        0.067 
syntax-designator-chars                    1        0.067 
get-buffer-create                          1        0.067 
mime::content-info/rcnum                   1        0.067 
erase-buffer                               1        0.067 
canonicalize-inst-list                     1        0.067 
window-displayed-height                    1        0.067 
mail-extract-address-components            1        0.067 
remove-message                             1        0.067 
raw-append-message                         1        0.067 
make-char-table                            1        0.067 
frob-face-property-1                       1        0.067 
frob-face-font-2                           1        0.067 
gnus-mode-string-quote                     1        0.067 
nnmail-find-file                           1        0.067 
gnus-point-at-eol                          1        0.067 
sort-reorder-buffer                        1        0.067 
get-custom-frame-properties                1        0.067 
gnus-configure-frame                       1        0.067 
frame-type                                 1        0.067 
#<compiled-function (from "message.elc") nil "...(8)" [get-text-property message-rank 10000] 3>    1        0.067 
-----------------------------------------------------------
Total                                      1496     100.00


One tick = 1 ms


FAST



Function Name                              Ticks    %/Total
=======================================    =====    =======
(in garbage collection)                    70       22.436
string-match                               25       8.013 
directory-files                            23       7.372 
match-string                               18       5.769 
#<compiled-function (from "nnheader.elc") (file) "...(27)" [file nnheader-numerical-short-files ^[0-9]+$ string-to-int string-match match-string 0] 4>    16       5.128 
put-text-property                          11       3.526 
load-internal                              10       3.205 
re-search-forward                          10       3.205 
x-get-resource                             10       3.205 
next-single-property-change                8        2.564 
check-menu-syntax                          8        2.564 
insert-buffer-substring                    7        2.244 
x-get-resource-and-maybe-bogosity-check    7        2.244 
text-prop-extent-paste-function            6        1.923 
string-to-int                              5        1.603 
looking-at                                 5        1.603 
syntax-string-to-code                      5        1.603 
put-char-table                             5        1.603 
x-init-face-from-resources                 5        1.603 
add-text-properties                        4        1.282 
redisplay-echo-area                        3        0.962 
x-bogosity-check-resource                  3        0.962 
map-extents                                2        0.641 
get-text-property                          2        0.641 
mapcar                                     2        0.641 
highlight-headers                          2        0.641 
custom-declare-variable                    2        0.641 
custom-add-to-group                        2        0.641 
raw-append-message                         2        0.641 
std11-field-end                            2        0.641 
gnus-article-highlight-headers             2        0.641 
format                                     2        0.641 
subst-char-in-region                       1        0.321 
copy-keymap                                1        0.321 
append-message                             1        0.321 
gnus-cite-add-face                         1        0.321 
make-extent                                1        0.321 
regexp-quote                               1        0.321 
make-face                                  1        0.321 
init-face-from-resources                   1        0.321 
valid-instantiator-p                       1        0.321 
file-exists-p                              1        0.321 
x-frob-font-slant                          1        0.321 
modify-syntax-entry                        1        0.321 
syntax-table-p                             1        0.321 
gnus-cite-parse                            1        0.321 
message-next-header                        1        0.321 
featurep                                   1        0.321 
window-displayed-height                    1        0.321 
custom-initialize-reset                    1        0.321 
mime-preview/display-content               1        0.321 
custom-declare-face                        1        0.321 
set-face-underline-p                       1        0.321 
set-face-property                          1        0.321 
vectorp                                    1        0.321 
gnus-configure-frame                       1        0.321 
gnus-all-windows-visible-p                 1        0.321 
frame-type                                 1        0.321 
lsh                                        1        0.321 
nnml-server-opened                         1        0.321 
-----------------------------------------------------------
Total                                      312      100.00


One tick = 1 ms


********* Strace *********


Below is an excerpt from an Strace.

I used "script" to record all output and then I typed "strace xemacs"
then iconified the window. In another window I used "tail -f
typescript |grep open" so that I could see the corresponding open
calls as I used Gnus.

At this point I enter the redhat.list group:

open("/home/zcaceog/News/cache/nnml:redhat.list", O_RDONLY|O_NONBLOCK) = 8
open("/home/zcaceog/Mail/redhat/list/.overview", O_RDONLY) = 8
open("/home/zcaceog/News/cache/nnml:redhat.list/.overview", O_RDONLY) = 8
open("/usr/local/share/xemacs/site-lisp/gnus-score.elc", O_RDONLY) = 8
open("/home/zcaceog/News", O_RDONLY|O_NONBLOCK) = 8
open("/home/zcaceog/News/nnml:redhat.list.SCORE", O_RDONLY) = 8
open("/home/zcaceog/News/nnml:redhat.list.SCORE", O_RDONLY) = 8
open("/etc/localtime", O_RDONLY)        = 8

Here I select the first article:

open("/usr/local/share/xemacs/site-lisp/gnus-bcklg.elc", O_RDONLY) = 8
open("/usr/local/share/xemacs/site-lisp/gnus-async.elc", O_RDONLY) = 8
open("/home/zcaceog/Mail/redhat/list", O_RDONLY|O_NONBLOCK) = 8
open("/home/zcaceog/Mail/redhat/list", O_RDONLY|O_NONBLOCK) = 8
open("/home/zcaceog/Mail/redhat/list/17542", O_RDONLY) = 8
open("/usr/lib/xemacs-20.4/lisp/utils/highlight-headers.elc", O_RDONLY) = 8
open("/usr/local/share/xemacs/site-lisp/gnus-cite.elc", O_RDONLY) = 8
open("/usr/lib/xemacs-20.4/lisp/prim/sort.elc", O_RDONLY) = 8
open("/usr/lib/xemacs-20.4/lisp/utils/mail-extr.elc", O_RDONLY) = 8

The second, third, fourth ...

open("/home/zcaceog/Mail/redhat/list/17557", O_RDONLY) = 8
open("/home/zcaceog/Mail/redhat/list/17565", O_RDONLY) = 8
open("/home/zcaceog/Mail/redhat/list/17568", O_RDONLY) = 8
open("/home/zcaceog/Mail/redhat/list/17581", O_RDONLY) = 8
open("/home/zcaceog/Mail/redhat/list/17567", O_RDONLY) = 8
open("/home/zcaceog/Mail/redhat/list/17566", O_RDONLY) = 8 

Here I enter the hurricane group:

open("/home/zcaceog/News/cache/nnml:hurricane", O_RDONLY|O_NONBLOCK) = 8
open("/home/zcaceog/Mail/hurricane/.overview", O_RDONLY) = 8
open("/home/zcaceog/News/cache/nnml:hurricane/.overview", O_RDONLY) = 8
open("/home/zcaceog/News/nnml:hurricane.SCORE", O_RDONLY) = 8
open("/home/zcaceog/News/nnml:hurricane.SCORE", O_RDONLY) = 8

Here I select the first article:

open("/home/zcaceog/Mail/hurricane", O_RDONLY|O_NONBLOCK) = 8
open("/home/zcaceog/Mail/hurricane", O_RDONLY|O_NONBLOCK) = 8
open("/home/zcaceog/Mail/hurricane/8865", O_RDONLY) = 8
open("/home/zcaceog/News/cache/nnml:hurricane/.overview", O_RDONLY) = 8
open("/usr/lib/xemacs-20.4/lisp/utils/pp.elc", O_RDONLY) = 8
open("/home/zcaceog/News/nnml:hurricane.SCORE", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 8 

-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Felix Lee]

> > The problem isn't opening the group as I rarely select more that 100
> > articles. It's selecting the first article once I'm in the group.

> > Whichever article I select then takes about 10-15 seconds to
> > display. All articles selected after that are almost instantaneous
> > whether they are above or below the first article.

if you're using gnus-async, gnus is opening a second nntp
connection the first time you select an article.  this
happens synchronously, so you have to wait for it.
--

Re: Gnus as slow as molasses

[Felix Lee]

> Eze is talking about nnml access -- gnus-async (and nntp) aren't
> involved.

yeah, I realized that after I mailed that off :)

in penance, I just took a quick look at nnml, and I can't
seem to reproduce that behavior.  but I'm currently using
5.6.3, not 5.6.4...
--

Re: Gnus as slow as molasses

[Karl Kleinpaste]

Felix Lee <flee@teleport.com> writes:
> if you're using gnus-async, gnus is opening a second nntp
> connection the first time you select an article.

Eze is talking about nnml access -- gnus-async (and nntp) aren't
involved.

Re: Gnus as slow as molasses

[Lars Magne Ingebrigtsen]

Eze Ogwuma <typhoon@dircon.co.uk> writes:

> string-match                               264      17.647
> directory-files                            261      17.447
> match-string                               168      11.230

Does this mean that `directory-files' is called 261 times?  (I'm not
familiar with the output of `profile-keystrokes'.)

Anyways, I think the culprit is `nnheader-article-to-file-alist',
which is Slow in huge groups if you have jka-compr loaded.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus as slow as molasses

[Eze Ogwuma]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> 
> > string-match                               264      17.647
> > directory-files                            261      17.447
> > match-string                               168      11.230
> 
> Does this mean that `directory-files' is called 261 times?  (I'm not
> familiar with the output of `profile-keystrokes'.)

I'm sorry, I don't know either. I was told to try this by Hrvoje
Niksic, see the message below. I couldn't find any mention of it in
the XEmacs manuals.

> Anyways, I think the culprit is `nnheader-article-to-file-alist',
> which is Slow in huge groups if you have jka-compr loaded.

With or without this opening the first article is very slow. I've
found that not having comresssion in the .emacs file decreases the
time by ~33.3% however this is not the ~99.4% needed to remove the
problem.


Hrvoje Niksic <hniksic@srce.hr> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> 
> > This additional information was sent to someone as a reply.
> > 
> > The problem isn't opening the group as I rarely select more that 100
> > articles. It's selecting the first article once I'm in the group.
> > 
> > I have this in my .gnus file so I get to choose which article to
> > select:
> > ;; Don't select the first article automatically
> > (setq  gnus-auto-select-first nil)   
> > 
> > Whichever article I select then takes about 10-15 seconds to
> > display. All articles selected after that are almost instantaneous
> > whether they are above or below the first article.
> 
> Under XEmacs 20.4 you can use `M-x profile-key-sequence', press a key
> (say RET in the Group buffer), and get the results using
> `M-x profile-results'.  It should give you an idea of where the time
> is being spent.
> 

-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Lars Magne Ingebrigtsen]

Eze Ogwuma <typhoon@dircon.co.uk> writes:

> With or without this opening the first article is very slow. I've
> found that not having comresssion in the .emacs file decreases the
> time by ~33.3% however this is not the ~99.4% needed to remove the
> problem.

How many articles are there in the group?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus as slow as molasses

[Eze Ogwuma]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> 
> > With or without this opening the first article is very slow. I've
> > found that not having comresssion in the .emacs file decreases the
> > time by ~33.3% however this is not the ~99.4% needed to remove the
> > problem.
> 
> How many articles are there in the group?

Well I can't say how many were there when I sent that message and I
don't remember for sure which group it refers to. However since it was 
probably the largest group there would have been about 17400 articles
in the group with about 8000 unread. All this is according to Gnus so
it could be wrong.

(I actually put the information about the group sizes near the top of
the message you got the timing information from.)

-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Eze Ogwuma]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> 
> > Well I can't say how many were there when I sent that message and I
> > don't remember for sure which group it refers to. However since it was 
> > probably the largest group there would have been about 17400 articles
> > in the group with about 8000 unread. All this is according to Gnus so
> > it could be wrong.
> 
> A group with 17400 articles will take a long while to open.  Sorry.

I don't know if you've quite understood what is happening here:

1. I enter the group
2. Gnus generates a Summary buffer (without selecting the first article)
3. _Then_ I select an article.

The first article I select, whichever article it is takes a very long
time to display. Following that article selection is instantaneous. 

If I exit the Summary then re-enter it and select a different article
the same amount of time is needed as before. 

However if, when I re-enter the Summary buffer, I select the same
article as before then display is instantaneous (I have the backlog
set).
-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Lars Magne Ingebrigtsen]

Eze Ogwuma <typhoon@dircon.co.uk> writes:

> I don't know if you've quite understood what is happening here:
> 
> 1. I enter the group
> 2. Gnus generates a Summary buffer (without selecting the first article)
> 3. _Then_ I select an article.

I understand perfectly.  If the group contains 17000 articles,
selecting the first article will be Slow.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus as slow as molasses

[Eze Ogwuma]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> 
> > I don't know if you've quite understood what is happening here:
> > 
> > 1. I enter the group
> > 2. Gnus generates a Summary buffer (without selecting the first article)
> > 3. _Then_ I select an article.
> 
> I understand perfectly.  If the group contains 17000 articles,
> selecting the first article will be Slow.

Oh. Sorry.

Could you please tell me why this is the case.

-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Lars Magne Ingebrigtsen]

Eze Ogwuma <typhoon@dircon.co.uk> writes:

> Could you please tell me why this is the case.

Because nnml does a `directory-files'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Gnus as slow as molasses

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> If the group contains 17000 articles,
>> selecting the first article will be Slow.

Eze Ogwuma <typhoon@dircon.co.uk> writes:
> Could you please tell me why this is the case.

At the very least, kernel directory search time will be horrendous,
especially given the assumption that newer files will be listed near
the end of the directory.

How large is the directory itself?  That is, the byte-size, not the
file count.  I'd guess it's in the vicinity of 250Kbytes, maybe more.

Re: Gnus as slow as molasses

[Eze Ogwuma]

Karl Kleinpaste <karl@jprc.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> >> If the group contains 17000 articles,
> >> selecting the first article will be Slow.
> 
> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> > Could you please tell me why this is the case.
> 
> At the very least, kernel directory search time will be horrendous,
> especially given the assumption that newer files will be listed near
> the end of the directory.
> 
> How large is the directory itself?  That is, the byte-size, not the
> file count.  I'd guess it's in the vicinity of 250Kbytes, maybe more.

LS reveals a size of 277504k with an actual file size of 69MB
including the .overview file (4.3 MB). I didn't realize it would be so
large.

I suppose that now I need a good policy for archiving read messages. 
-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Eze Ogwuma]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Eze Ogwuma <typhoon@dircon.co.uk> writes:
> 
> > Could you please tell me why this is the case.
> 
> Because nnml does a `directory-files'.

Ahh. Had I know this I would have tried to find a way to reduce the
number of articles in the directory but I thought than nnml was good
for reading very large directories.

-- 
Eze Ogwuma

Re: Gnus as slow as molasses

[Hrvoje Niksic]

Eze Ogwuma <typhoon@dircon.co.uk> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Eze Ogwuma <typhoon@dircon.co.uk> writes:
> > 
> > > string-match                               264      17.647
> > > directory-files                            261      17.447
> > > match-string                               168      11.230
> > 
> > Does this mean that `directory-files' is called 261 times?

No, it's just a count of profiling signals.  In XEmacs 21 the profiler 
will also have a call count; until then, you can use Elp.

> I couldn't find any mention of it in the XEmacs manuals.

It's a relatively new facility.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
4.  Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if
    it bee the sig of the Inner Circle.