Optimizing Hunter to

Compute Change Points

in Constant Time ��and �What that Means �for UX

Henrik Ingo

16th ACM/SPEC�International Conference of Performance Engineering�Toronto, Canada, May 5-9, 2025

Historical context for a rather technical presentation

blog.nyrkio.com

In 12 months:

63 regressions

17 improvements

Missed 1 regression (reported by user)

E-divisive means for dummies

(Formally: Matteson & James, 2013)

E-divisive means for dummies

(Formally: Matteson & James, 2013)

E-divisive means for dummies

(Formally: Matteson & James, 2013)

E-divisive means for dummies

(Formally: Matteson & James, 2013)

E-divisive means for dummies

(Formally: Matteson & James, 2013)

Optimizations reported in the MongoDB paper

Optimizations reported in the Datastax paper

Optimizations by Nyrkiö (not previously reported)

What does it mean in practice?

​

Originally computing change points was necessarily a batch job scheduled separately.

​

Realizing that the computation can be done synchronously, while the user is browsing results allows to expose the parameters of the algorithm so the user can interactively find the optimal sensitivity

What does it mean in practice?

Future: The Hunter improvements include a 2-pass approach, computing a superset of "weak changepoints".

• We could send also these to the client, which would allow to show in the UI that "you have 5 more change points that would be shown if you choose a higher p-value".

Conclusions

Change Point Detection to catch performance regressions first reported 5 years ago, work started 8 years ago

Improved by a handful of contributors, without much coordination, and mostly as a side project

In fact, ICPE papers the main knowledge transfer vehicle!

Also, publishing a paper was often the motivation for managers to approve publishing code as open source

This loosely knit community of practitioners took the e-divisive algorithm from O(n^3) to O(1)

Benchmark improvement up to 300 thousand x faster

Hunter �Apache Otava (incubating)

Nyrkiö