[Whoops, sent this from the wrong email address before... resent]
Ralph Corderoy writes:
Is there any way I can completely avoid the giant folder check? I
can't think of why it is being done time after time for simple program
invokations that, for example, refer to a specifically enumerated
message.
I do not have `unseen-sequence' set in .mh_profile, so it does not need
updating.
...
Since .mh_sequences is first read and then written to, it looks like the
"make it match reality" code runs every time. I agree, when `42' is
explicitly given, and there's no unseen sequence that might need
updating, .mh_sequences could be skipped entirely. When `42' is
omitted, then .mh_sequences needs reading to get `cur', but it need not
be written, leaving detritus in sequences to be cleaned up by a later
command that cares. In both cases, the getdents() aren't needed.
BTW, getdents() is also impacted by ,314 and friends that clutter a mail
folder. On a busy, unpacked, +inbox, they can grow many.
Hmm.
[Note: I've also seen a bunch of other responses on this overall topic
"do we have to do all this work all the time"]
Let me describe the scenario I'm expecting to see a little more, and
it might elucidate some angles.
Essentially for each major "page" or "view" used, we would expect to
see 1 or 2 commands that represent the major "task" the user is
performing, but then MH-W ends up needing to do from a few to even
many more to display to or interact with the end-user.
Let me show 2 example scenarios:
1) "scan view"
1.1 The "pick" command (which I've optimized out if your list
is just a message list).
1.2 The "scan" comand.
1.3 The "mark -list -sequence ..." command to get the list of
messages marked via the "unseen" sequence, for colorization.
NOTE: Since MH-W already has to qualify messages in any sequence
returned, there is no point in anything but the raw sequence
listing.
2) "message view"
1.1 MH-W needs to start by looking at what is in the message
via "mhlist", it would do this normally to update the "cur"
or whatever else needs updating.
1.2 MH-W makes several calls to "scan" with formats to extract
header fields.
1.3 Extract each of the components needed to display the message.
This could be from 1 to many, for example for inlined images
in an HTML email.
So, the result of all of this is that I'm forming a model which suggests
maybe I should ask if we could have ... I'm not sure what to call it ...
a "-nocheck" switch which would not need to check the folder nor
update any sequences, and would be allowed to simply fail if you tried
to use a relative or sequence-based message ID.
Examples of what I'm asking for:
1) "show -nocheck 150"
Would blindly access message 150, would not update "cur" or any
other sequence.
2) "mhlist -nocheck <options> 150"
Would operate on message 150 with, again, no update of "cur" or
any other sequence.
3) "mark -list -nocheck -sequence ..."
Would give the list in the raw form without needing to do anything.
To summarize, my interest in making these faster isn't so much for the
*single* invokation case, but the fact that MH-W may have to call them
many to even 10+ times in various combinations for one percieved result
for the end-user (the "message view" is the big poster child for this).
... Not that various Hacker-types would mind having a faster mechanism
when they know what they are doing to access email in stupendously
large folders...
It is straightforward to have each of the MH-W pages have at least one
activity which would update cur/the sequences, but having it done 10
times in a row seems excessive/wasteful and as I've demonstrated above
could be prohibitive.
How does this sound?
--
Erich Stefan Boleyn <erich(_at_)uruk(_dot_)org> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers