Should enable_debug_timings be recursive?

[henriquebecker91]

I am developing a package that could make good use of your package. It is a collection of mathematical models using JuMP that may be run with different solvers and some models have preprocessing steps that may or may not take a considerable amount of time. I was thinking of using the macro timeit_debug and the method enable_debug_timings, allowing me or an user of the package to disable the timings (useful not only to get max speed, but also to debug if the timings are or not taking a negligible time). However, my main package module has many submodules (one for each model to be more exact). And seems to me that enable_debug_timings just acts on the module that was passed as parameter and do not change the situation for the submodules, you think it is possible to create a flag to make it recursive? If you think it is possible and it is a reasonable thing to do, then I can work on a pull request.

[KristofferC]

Just to point out, the overhead of a timed section is on the order of hundreds of nanoseconds so, with the exception of quite tight loops, the overhead of timings is negligible and can just unconditionally be enabled.

Regarding recursiveness, it probably makes sense to have an enable_debug_timings_recursive.