From: Wes Hardaker <wes@hardakers.net>
Subject: Re: elp results: entering an nnimap folder
Date: Thu, 31 Jan 2002 08:00:46 -0800 [thread overview]
Message-ID: <sdg04m5x3l.fsf@wanderer.hardakers.net> (raw)
In-Reply-To: <2naduvnrk0.fsf@zsh.cs.rochester.edu> (ShengHuo ZHU's message of "Wed, 30 Jan 2002 22:10:55 -0500")
>>>>> On Wed, 30 Jan 2002 22:10:55 -0500, ShengHuo ZHU <zsh@cs.rochester.edu> said:
ZSH> gnus-summary-prepare, 63.7%, including gnus-user-format-function-b,
ZSH> 15.8%, and gnus-thread-total-score 14.5%. If you turn off BBDB and
ZSH> sorting by total-score, it may speed up a lot.
Yep, I'm aware that's a big hit. But I can't live without it ;-)
It's turned off for my main inbox groups but for mailing lists and
news groups I need it badly to sort out the cruft.
ZSH> gnus-select-newsgroup 27.0%, including gnus-retrieve-headers
ZSH> 13.1% (the time returned by elp is not actual time it consumed)
ZSH> and gnus-get-newsgroup-headers-xover 7.7%. If the NOV of some
ZSH> articles are not cached by Agent, the performance depends on the
ZSH> speed and latency of the network.
I know the agent is supposedly downloading and stashing NOV
information these days, but it hasn't seemed to help me a whole bunch
(but I haven't double checked that it's actually happening either).
Well, the .overview file for this group is modified recently, so I
guess it is at least stashing information. Of course the file is
really large... I bet I need to run gnus-agent-expire, which I
haven't done in ages.
There. Now I have. Wonder if it'll help? I guess I'll find out.
ZSH> This result seems much different. The running time of
ZSH> gnus-summary-prepare, 5.6%, is cut down a lot. But the running
ZSH> time of gnus-select-newsgroup, 94.1%, including
ZSH> gnus-retrieve-headers, 27.5%, and
ZSH> gnus-get-newsgroup-headers-xover, 47.4% is too much. This is
ZSH> similar to Daniel Pittman's report. Maybe decoding headers in
ZSH> gnus-get-newsgroup-headers-xover takes most of the running time.
Yep. Folders like that one are crucial for me, unfortunately, as
they're folders with really old bugs or mail messages with important
info in them for the ucd-snmp package that I can't throw away. I
could just copy them around to get re-ordering which would probably
help. But, IMHO, that shouldn't be a requirement (which I guess is my
point).
--
"Ninjas aren't dangerous. They're more afraid of you than you are of them."
prev parent reply other threads:[~2002-01-31 16:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-30 22:08 Wes Hardaker
2002-01-31 3:10 ` ShengHuo ZHU
2002-01-31 16:00 ` Wes Hardaker [this message]
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=sdg04m5x3l.fsf@wanderer.hardakers.net \
--to=wes@hardakers.net \
/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).