Re: patch: improved TSLICE, thread navigation, ...

[Earl Hood <ehood@hydra.acs.uci.edu>]

On July 1, 2001 at 12:50, Eddie Kohler wrote:

> I believe this behavior is reasonable and useful, and that MHonArc should
> support it. But TNEXT and TPREV currently prevent me from doing this
> without constantly going back to the thread index.

Behaviorial-wise, I aggree with you on how TNEXT and TPREV should behave
for TREVERSE.

> You may want to check out the cache_msg_pos() function in patched
> mhrcvars.pl. This function caches the results of compute_msg_pos(), which
> may make things *faster* overall (particularly for LINKs). The extra
> TNEXT/TPREV overhead is small anyway, and only takes effect at the
> end/beginning of a thread when TREVERSE is on.

>From a quick look at the code you sent, your cache attempt does not
appear to work since you reset it each time replace_li_var() is called
(losing what you cached).  The cache structure must exist outside of
replace_li_var(), and be reset when a new archive is opened.  I could
be wrong with this assessment since it is based on looking at the
patch data itself.

Side note: A primitive API exists to allow one to process multiple
archives in a single process if done in sequence.  Hence, some
resources have to be handled via mhdysub.pl or handled properly to
not cross-pollute to another archive.  Something easier to manage
if MHonArc is redone to escape its Perl 4 legacy.

I like the idea of a cache, but it can be quite expensive for large
archives where memory usage can be a problem.  It is one of those
features that must be profiled to see if it is worth having.  Note,
TNEXT/TPREV should only be expensive if TREVERSE is set since there
is already other potential hits one takes when using TREVERSE (mainly
when MULTIPG is active).

--ewh

P.S.  Your MUA dropped the subject text in your reply.