From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10191 invoked by alias); 24 Oct 2006 15:16:53 -0000 Received: (qmail 10182 invoked by uid 22791); 24 Oct 2006 15:16:53 -0000 X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Oct 2006 15:16:48 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9OFGjgB030475; Tue, 24 Oct 2006 11:16:45 -0400 Received: from pobox.hsv.redhat.com (pobox.hsv.redhat.com [172.16.16.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9OFGj67026907; Tue, 24 Oct 2006 11:16:45 -0400 Received: from [172.16.17.170] (dhcp-170.hsv.redhat.com [172.16.17.170]) by pobox.hsv.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9OFGiYk015603; Tue, 24 Oct 2006 11:16:44 -0400 Message-ID: <453E2E60.8070701@redhat.com> Date: Tue, 24 Oct 2006 15:16:00 -0000 From: David Smith User-Agent: Thunderbird 1.5.0.7 (X11/20061004) MIME-Version: 1.0 To: "Stone, Joshua I" CC: systemtap@sources.redhat.com Subject: Re: precompiled probing scenarios References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00240.txt.bz2 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)