Current STAP_TIMING (-t) code only keeps a single Stat* object per base (end-user script-level) probe. This means that for a script such as 'probe syscall.* {}' we get only a single -t summary line. It is just as useful sometimes to have a detailed list of times/hits per low-level probe point rather than script-level, so that each 'kernel.function("sys_foo")' created for syscall.* can get its own timing statistic. This should be a new option (rather than a change to -t's current behavior). See also bug #10788 Implementation would focus on translate.cxx:emit_common_header(): oss << "c->statp = & time_" << dp->basest()->name << ";" << endl; // -t anti-dupe where the basest() part would be nuked. Instead, a per-pp() Stat would have to be declared elsewhere and referenced here.
NB the NBs in c_unparser::emit_probe: // NB: statp is just for avoiding designation as duplicate. It need not be C. // NB: This code *could* be enclosed in an "if (session->timing)". That would // recognize more duplicate probe handlers, but then the generated code could // be very different with or without -t. oss << "c->statp = & time_" << v->basest()->name << ";" << endl; So if we change the name assigned to statp, then we will end up changing the duplication finding after all, as they get assigned to different timing globals. I have an idea that we could shift to using a string-indexed map of stats instead, so every probe gets the same statp code emitted (and thus duplication finding can work to its fullest). The different -t variations would just select which string is used for the map lookup, e.g. c->probe_point, c->probe_name, or something else. We don't yet have a runtime string representing basest(), but it could be added. Frankly, I would say just abandon timing at the basest level and just toggle between pn/pp granularity.
commit a1e3433a04fa63eb9c777003c467b963cd514f16 Changed the -t option rather than adding a new option. The -t option now displays information based on probe point rather than the probe name. Each probe point also displays its respective derivation chain.
*** Bug 10788 has been marked as a duplicate of this bug. ***