Closed codefromthecrypt closed 11 months ago
I think there's a bug in the test score-simple plugin setup as it is too fast. I'll look into it.
PluginScore/test/params:_real-12 39818.0n ± 17% 350.1n ± 1% -99.12% (p=0.002 n=6)
ah right I didn't change the benchmarks to begin with PreFilter, so they were caching the result. fixing now
ok I fixed the benchmarks and updated the description about what's going on. If not clear I can elaborate more.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: codefromthecrypt, sanposhiho
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Ah no, you cannot use the button yet. I will give lgtm again later.
/lgtm
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Before, each plugin would unmarshal the pod being scheduled. For example, PreFilter, Filter, Score would unmarshal the same pod three times. This exposes an internal field
cyclestate.Pod
, reset on PreFilter, which is shared for all plugins. One side-effect to this is that all TinyGo plugins will always implement PreFilterPlugin implicitly. In other words, they will export the "prefilter" function even if they have not calledprefilter.SetPlugin
.Which issue(s) this PR fixes:
NONE
Special notes for your reviewer:
xxx.Plugin = Y
toxxx.SetPlugin(y)
are in the RATIONALE.mdDoes this PR introduce a user-facing change?
NONE
What are the benchmark results of this change?
The baseline of benchmarks changed because now all of them call PreFilter first. While there is an increase in latency of the "small" tests, this is nothing for concern because the data isn't of realistic size. The increased time is due in part to the second callback. What's important is when multiple plugins are executed, the latency is significantly down. This is the case in
PluginPrefilterFilterAndScore
.