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
(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