This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/10234] clean up aggregate hard-coded logic
- From: "mcermak at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 13 Sep 2016 09:56:06 +0000
- Subject: [Bug runtime/10234] clean up aggregate hard-coded logic
- Auto-submitted: auto-generated
- References: <bug-10234-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=10234
Martin Cermak <mcermak at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mcermak at redhat dot com
--- Comment #3 from Martin Cermak <mcermak at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #0)
> the runtime makes a number of unfortunate assumptions about aggregate
> objects:
>
> - that all of count/min/max/sum should be tracked
The @variance() operator, introduced per PR11308, comes with a mechanism
tracking the stat operators used with given global within the script. This
mechanism is being used to skip variance calculations if they are not needed.
Variance is significantly more expensive than min or max, so the most
beneficial optimization already is in place. Looking at min, max, sum and
count, I think the effect of optimizing them out is close to unmeasurable:
I've been repeatedly running following command on my workstation:
=======
rm -rf ~/.systemtap; for k in `seq 1 500`; do stap -t -g --suppress-time-limits
-e 'global x probe oneshot{ for(i; i<40000; i++) x<<<i println(@count(x)) }' |
sed 's/avg//g' | awk -F\/ '/^begin/ {print $2/1e3}'; done | awk '{ total += $1;
count++ } END { print total/count }'
=======
and comparing results related to presence versus absence of the following
patch:
=======
diff --git a/runtime/stat-common.c b/runtime/stat-common.c
index e58b1c2..70a46ea 100644
--- a/runtime/stat-common.c
+++ b/runtime/stat-common.c
@@ -306,11 +306,13 @@ static void __stp_stat_add(Hist st, stat_data *sd,
int64_t val)
sd->_M2 = 0;
} else {
sd->count++;
+ /*
sd->sum += val;
if (val > sd->max)
sd->max = val;
if (val < sd->min)
sd->min = val;
+ */
/*
* Following is an optimization that improves performance
* in case @variance() isn't used with given global.
$
=======
The times I got having these lines commented out were: 879, 815, 820, 830, 925,
741, 834, 890.
The times I got not having these lines commented out: 1049, 1010, 1047, 953,
976.
Based on the above I'd say, it might make sense to conditionally optimize this
whole block out if respective stat ops are not in use. My nose tells me that
doing more targeted optimizations would not be beneficial. Thoughts?
--
You are receiving this mail because:
You are the assignee for the bug.