For many operations on and with polynomials, we have different algorithms that do the same thing but exhibit different performance characteristics. In the public API, we expose dispatcher methods that automatically chose the fastest algorithm. To the end user, this is transparent. The dispatch decision points are hardcoded. Examples of such decision points are FAST_MULTIPLY_CUTOFF_THRESHOLD, REDUCE_BEFORE_EVALUATE_THRESHOLD_RATIO, or the ad-hoc constant against which squared_coefficient_len is compared in Polynomial::square().
In order to simplify performance tuning, both for us when trying to identify better defaults and for power users that want to squeeze everything out of their machines, these decision points should be configurable. e9fae6a introduces the config module which could act as the central configuration place.
I don't think that it must be comprehensive what each of the decision points means in detail. Given their number and interdependencies, such a task seems infeasible anyway; if a detailed understanding of some particular decision point is required, it's probably easier to read the code instead.
For many operations on and with polynomials, we have different algorithms that do the same thing but exhibit different performance characteristics. In the public API, we expose dispatcher methods that automatically chose the fastest algorithm. To the end user, this is transparent. The dispatch decision points are hardcoded. Examples of such decision points are
FAST_MULTIPLY_CUTOFF_THRESHOLD,REDUCE_BEFORE_EVALUATE_THRESHOLD_RATIO, or the ad-hoc constant against whichsquared_coefficient_lenis compared inPolynomial::square().In order to simplify performance tuning, both for us when trying to identify better defaults and for power users that want to squeeze everything out of their machines, these decision points should be configurable. e9fae6a introduces the
configmodule which could act as the central configuration place.I don't think that it must be comprehensive what each of the decision points means in detail. Given their number and interdependencies, such a task seems infeasible anyway; if a detailed understanding of some particular decision point is required, it's probably easier to read the code instead.