Rather than flipping the order for micro-savings we might not actually get in practice, we should only re-order them when they are some non-trivial difference in speed. 10%?
Description
Description
Details
Details
Related Changes in Gerrit:
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Only re-order implementations if new fastest beats previous by 20% | mediawiki/extensions/WikiLambda | master | +57 -7 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T329138 ApiPerformTest: Revisit implementation ranking strategies | |||
| Resolved | DMartin-WMF | T330698 Only re-order function implementations if they're more than X% faster/slower than each other |
Event Timeline
Comment Actions
I think this work is relatively do-able in a much smaller amount of time, so I'll keep it open.
Comment Actions
Change 911420 had a related patch set uploaded (by David Martin; author: David Martin):
[mediawiki/extensions/WikiLambda@master] Only re-order implementations if new fastest beats previous by 20%
Comment Actions
Change 911420 merged by jenkins-bot:
[mediawiki/extensions/WikiLambda@master] Only re-order implementations if new fastest beats previous by 20%