> > Make timings more consistent by temporarily disabling GC. > > Shouldn't this be an option at best? I think not. The default behavior should be the one that gives the most consistent timings between runs. > What if I want to time some code > that expects GC to be on? >>> Timer(stmt, 'import gc; gc.enable()'.timeit() If desired, I can add a note to that effect in the docs. However, GC is such a random event (in terms of when it occurs, what it affects, how much time it takes, and the state of the system) that you would always want it off unless you're specifically measuring GC performance across two sets of code that handle GC differently. GC performance does make a difference when measuring the performance of a whole, memory intensive application; however, that tends to fall outside the scope and purpose of the module. If you really want an option, I can put it in, but why clutter the API with something that few people care about or understand. An alternative is to stick with my original idea of running a gc.collect() before each timing pass. I would have done that but Tim's comment left me with doubts about whether it was the right thing to do. On the surface it makes sense and empirical tests show that the timings do become more stable. However, trashing the cache before each run may create timings that don't reflect a normal operating environment (though the timeit environment is already anything but normal). Raymond
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4