Re: precompiled probing scenarios

[David Smith <dsmith@redhat.com>]

Stone, Joshua I wrote:
> I saw that you checked in the caching code, so I finally got around to
> trying it.  :)
 >
> For the most part, it seems to work really nicely.  The caching is
> essentially transparent, which makes for a positive experience when your
> scripts startup faster.

Thanks for trying it.  Yep, its in.  Hopefully no one else has noticed 
because it is fairly transparent (except perhaps for your growing 
~/.systemtap/cache directory).

The faster script startup is really nice, especially on slower hardware 
(like my test box - a 1Ghz P3).

Here's an extreme example.  stap -p4 testsuite/systemtap.stress/sys.stp 
takes 0:06:18 uncached and only 0:00:07 cached.

A full "make installcheck" run takes 0:41:05 uncached and 0:15:39 cached.

BTW, a "make installcheck" should work correctly, cached or uncached. 
Next on my todo list is adding cache tests.

> There's a few trials I did though where caching opportunities were
> missed.  I'll admit freely that these are perhaps too nitpicky, so we
> can treat it as a low-priority enhancement.
> 
> 1. probe begin { exit() }
> 2. probe begin { exit(); }
> 3. probe begin { exit() a=1 }
> 
> 2 and 3 actually hash the same, since elision turns 'a=1' into an empty
> statement (';').  We should to be able to tell that these are all the
> same, but since the pass-2 output leaves in all semi-colons, the hash is
> different.  It ought to be pretty easy to normalize empty statements
> away, so minor differences like this don't matter.
> 
> A harder scenario to address is this:
> 
> 4. probe begin, end { exit() }
> 5. probe end, begin { exit() }
> 
> Again, with some fancy normalization, we should be able to identify
> these as equal.  And actually, the seemingly-unrelated work in
> probe-grouping would probably help here, if the pass-2 output were
> ordered in a deterministic manner.  Stap already does some of this,
> e.g., by ordering functions before probes.
> 
> It's likely rare that the differences between scripts will be so small,
> so these optimizations may not matter.  But if anyone's bored, or has an
> intern with nothing to do, this may be a simple enhancement.

Hmm.  Just for fun, I decided to see if the pass 3 output of [1. 2.] or 
[4. 5.] would compare equally.  They don't.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)