From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11296 invoked by alias); 24 Oct 2006 00:29:56 -0000 Received: (qmail 11287 invoked by uid 22791); 24 Oct 2006 00:29:55 -0000 X-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_40 X-Spam-Check-By: sourceware.org Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Oct 2006 00:29:53 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga09.intel.com with ESMTP; 23 Oct 2006 17:29:52 -0700 Received: from scsmsx332.sc.intel.com (HELO scsmsx332.amr.corp.intel.com) ([10.3.90.6]) by orsmga001.jf.intel.com with ESMTP; 23 Oct 2006 17:29:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,344,1157353200"; d="scan'208"; a="149570686:sNHT20975507" Received: from scsmsx413.amr.corp.intel.com ([10.3.90.32]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Oct 2006 17:29:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: precompiled probing scenarios Date: Tue, 24 Oct 2006 00:29:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: precompiled probing scenarios Thread-Index: Acb24uAfVFzpe0fIS4SfUukgyFJ+sgAHTq4Q From: "Stone, Joshua I" To: "David Smith" Cc: X-OriginalArrivalTime: 24 Oct 2006 00:29:52.0009 (UTC) FILETIME=[854E1F90:01C6F703] 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/msg00237.txt.bz2 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. 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=3D1 } 2 and 3 actually hash the same, since elision turns 'a=3D1' 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. Josh