Re: [Nmh-workers] m_getfld branch merged

[norm]

David Levine <address@hidden> 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