On Tue, May 22, 2012 at 4:04 PM, <chip.benn...@exeloncorp.com> wrote: > Often a D program is easier to read if you break up a complex predicate into > separate clauses, but I was wondering if you sacrifice script performance to > do that. For example, the following two D programs do the same thing (Do a > 20 second interval quantize of pread/pwrite block sizes for a specific > Oracle DB instance). Clearly “ora1.d” is easier to read, but is “ora2.d” > more efficient? >
What's your goal here, to make the script run faster when it actually has work to do, or to minimize the impact of the script on the system overall? If you want to minimize the impact of the script, you can take advantage of predicate caching. (You can find this in the DTrace documentation in the chapter on performance considerations.) The predicate cache lets you shortcut a lot of processing in those cases where you know the predicate is going to fail. You're getting some advantage from it already in ora1.d with the / execname == "oracle" / predicate. The first time a thread for some other process hits this predicate and fails, it will store the cache ID for this predicate. If the same thread hits the predicate again, the stored cache ID matches the predicate's cache ID, and you kick out immediately rather than processing the predicate again. You could benefit further by making this->dbinst a thread-local variable. Given that you're changing that variable every time you hit the first clause, though, you would keep invalidating the predicate cache. To maximize your use of the predicate cache, only set self->dbinst if it's not already set (i.e., / execname == "oracle" && !self->dbinst /.) You'd also want to stop using the parmDBinst variable. Because it's a global variable, any predicate using it is uncacheable. $$1 is cacheable, though, so you can just use that directly. Chad _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
