This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/11695] DWIM promotion of ++ to <<<
- From: "mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 14 Jun 2010 09:26:56 -0000
- Subject: [Bug translator/11695] DWIM promotion of ++ to <<<
- References: <20100611141707.11695.fche@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From mjw at redhat dot com 2010-06-14 09:26 -------
(In reply to comment #2)
> So this transformation is only worthwhile when updating the value is more common
> than reading it.
The example that triggered this was like that:
$ stap -e 'global modules;
probe timer.profile { if (target() == pid()) modules[umodname(uaddr())]++ }
probe end { foreach ([m] in modules- limit 5)
{ printf("%4d:%s\n", modules[m], m) } }' -x `pidof firefox`
There are two advantages to using aggregates. It is "cheaper" in this use case.
And you don't necessarily need to write the end probe since systemtap detects
that it is only written to, so will generate the end probe printing it itself.
(That is bug #6954 for global arrays).
The disadvantage is that is it slightly obscure (you don't actually want the
whole aggregate, only the @count). And that the generated printing of the global
is somewhat messy (you get the whole aggregate printed out).
It might always be a win for global arrays that are never read.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11695
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.