Chad, That was very helpful, thank-you.
So it sounds like you're saying that if the check expression has no cacheable components, it doesn't matter if I put the check in the predicate, or if I break the logic into two clauses and put the check in the first clause, with a thread-local variable to trigger the second clause. Or at the least, I should try to break out the cacheable parts of the check expression, and include that in the predicate. So a macro, like $$1 is cacheable, but an inline constant isn't? I guess the post-macro parsing of "D" sees $$1 the same as "abc", so I suppose that makes sense. But an inline constant is just as fixed as a quoted string, so I'd think it would be a good candidate for caching. I had a similar issue back in 2007 where you couldn't use an inline string as the printf format. And I see that still hasn't changed. Oh well. Chip Bennett Exelon Corporation BSC-IT Infrastructure & Operations UNIX Production Engineering 10 South Dearborn - 45th floor, Cube NW-008 Chicago, IL 60603 312-394-4245 direct / 312-394-7354 fax chip.benn...@exeloncorp.com -----Original Message----- From: Chad Mynhier [mailto:cmynh...@gmail.com] Sent: Wednesday, May 23, 2012 10:45 AM To: Bennett, Chip:(BSC) Cc: dtrace-discuss@opensolaris.org Subject: Re: [dtrace-discuss] Predicate vs. separate clause performance 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 ----------------------------------------- ************************************************** This e-mail and any of its attachments may contain Exelon Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Exelon Corporation family of Companies. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. Thank You. ************************************************** _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
