David Levine <levinedl(_at_)acm(_dot_)org> writes:
Ken wrote:
Ok, I'm wondering about this ... I see that the big
difference at least from a system call trace is the calls
to lseek(), which I guess are resulting from calls from
fseek() or ftell(). So do a lot of nmh programs use
fseek() to change the stream pointer mid-stream? I ask
because maybe programs like scan could tell m_getfld()
that they don't need to keep track of that stuff (or the
programs that care about that could tell m_getfld () that
they do care about that).
Right, inc/scan could get away without it. I'll look into
it, it shouldn't be difficult to slip in a bypass for them.
Did you notice the number of calls to open(2) for a MIME
message? One per part, plus the seek to the start of the
part. parse_mime() needs tilling. Most the mh* programs
rely on it.
I only understand about every 70% of this discussion, so I am talking out
of turn, and and maybe nonsense. But to the extent I understand the
discussion, you guys are investing time and effort to make nmh faster. But
consider:
~ folder +gone
gone+ has 10702 messages (9913-24409).
time scan > /dev/null
real 0m0.477s
user 0m0.307s
sys 0m0.169s
time pick -search searchAllOfEveryMessage
pick: no messages match specification
real 0m1.961s
user 0m1.769s
sys 0m0.189s
So nmh is scanning 10,702 messages in half a second and reading all of every
one of them in 2 seconds.
Is it really worth expending such high octane talent, to make nmh faster
?
If I'm talking nonsense, forgive me.
Norman Shapiro
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers