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

[Eddie Kohler <kohler@aciri.org>]

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
patches.)

love,
ed