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

2001-07-04 01:36:21
More on caching compute_msg_pos results.

I measured wall clock benchmarks for a long MHonArc run (531 messages, 4
indexes, TREVERSE) with five options for caching compute_msg_pos. In all
cases, the cache is small: it corresponds to at most one $index at a time.

        (0) No caching whatsoever.              ~20.8 sec

        (1) Caching within one run.             ~21.5 sec
            This is the degenerate form of
            caching in the original patch: the
            cache is maintained, but never used.
            Demonstrates cache overhead.

        (2) Only nested caching.                ~20.8 sec
            This was what I intended to implement:
            the cache works across nested invocations
            of &replace_li_var.

        (3) Caching across variables.           ~19.5 sec
            This adds the &replace_li_vars function
            I described in the last mail, so that
            the cache works across replacements of
            different variables in the same source text.

            Specifically, code like this:
   ($template = $SSMARKUP) =~ s/$VarExp/&replace_li_var($1,$index)/geo;
   print $msghandle $template;
            is transformed into:
   print $msghandle &replace_li_vars($SSMARKUP, $index);
            where &replace_li_vars() maintains the cache.

        (4) = (3) + persistence.                ~18.8 sec
            In this variant, &replace_li_vars will
            preserve the previous cache, if the
            previous cache was for the same message
            index. (This might cause problems for
            the multiple-archive case you mention.)

So caching strategy 4 makes MHonArc about 10% faster on this application.

(NB: None of the 5 options correspond to vanilla MHonArc b/c of other


<Prev in Thread] Current Thread [Next in Thread>