Make performance thresholds configurable #263
Description
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.