-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
execution: reorganize function operators #285
execution: reorganize function operators #285
Conversation
3108c8a
to
48cf5cb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love the cleanup, awesome work !
StepTime int64 | ||
SelectRange int64 | ||
ScalarPoints []float64 | ||
Offset int64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to pass Offset
and SelectRange
via a clojure when creating the function? These values should be constant and do not change between steps, so we might get a small speed up if there are less arguments to put on the stack before the function call.
The arguments are also optional for most functions so there might be an unnecessary overhead for something like sum_over_time
.
execution/scan/functions.go
Outdated
}, | ||
"xincrease": func(f functionArgs) sample { | ||
if len(f.Samples) == 0 { | ||
return invalidSample |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should remove invalidSample
in favour of an ok
return argument to indicate whether the function returns any value. The return args would then be float64, *histogram.FloatHistogram, bool
. We also don't need the timestamp of the result sample since that comes from the step itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that sounds much better! thanks ill do that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done! it has some effect
on main:
RangeQuery/clamp-8 632.5m ± ∞ ¹ 102.5m ± ∞ ¹ -83.79% (p=0.008 n=5)
vs PR
RangeQuery/clamp-8 631.62m ± ∞ ¹ 85.65m ± ∞ ¹ -86.44% (p=0.008 n=5)
execution/function/functions.go
Outdated
) | ||
|
||
var InvalidSample = Sample{T: -1, F: 0} | ||
var invalidSample = sample{T: -1, F: 0} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I would also consider removing invalidSample
in favour of 3 return arguments and dropping the timestamp.
execution/function/functions.go
Outdated
MetricAppearedTs *int64 | ||
type functionArgs struct { | ||
Samples []sample | ||
StepTime int64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to use this parameter in functions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah no, we only need it in range functions i think, not removing it was an oversight
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah its somewhat used in the time related functions; most of the time not though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i propose that we keep it for now and maybe handle the time based functions with a special sub operator here, wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i went ahead and removed it too because it would complicate the date functions. i now introduced noArgs and withArgs variants of them and got rid of step time most of the functions that way.
2a9c4ca
to
e39a8da
Compare
Signed-off-by: Michael Hoffmann <[email protected]>
Signed-off-by: Michael Hoffmann <[email protected]>
Signed-off-by: Michael Hoffmann <[email protected]>
e39a8da
to
1750741
Compare
Signed-off-by: Filip Petkovski <[email protected]>
9db0431
to
270c534
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks good now.
There was a regression in range selectors since the PR changed IsExtFunction
to use a map instead of comparing constants. That should now be fixed by doing the comparison once when creating the operator.
Signed-off-by: Filip Petkovski <[email protected]>
c2ae5b7
to
ef8e932
Compare
Benchmark results against main
|
scan
does not depend onfunction
anymore we can hide a couple structs and functions