Message223240
| Author |
pitrou |
| Recipients |
alex, arigo, georg.brandl, pitrou, serhiy.storchaka, steven.daprano, vstinner |
| Date |
2014年07月16日.17:43:38 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<53C6B9C5.5000508@free.fr> |
| In-reply-to |
<20140716164253.GG9112@ando> |
| Content |
Le 16/07/2014 12:43, Steven D'Aprano a écrit :
>
> I would *much* rather a parameter to timeit which controls whether or
> not to unroll, rather than timeit trying to guess whether you want it to
> unroll or not. PyPy can default to off, CPython to on, and other
> implementations can choose whichever default makes sense for them.
I think it is overkill. Apart from rather silly microbenchmarks, there
isn't much point in adding the loop unrolling facility. In real world,
even cheap operations such as "x = x + 1" will be surrounded by less
cheap operations, so if an improvement cannot yield tangible benefits
inside a simple for loop, then it doesn't deserve to be committed. |
|