This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2017年04月16日 06:12 by serhiy.storchaka, last changed 2022年04月11日 14:58 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 1161 | closed | serhiy.storchaka, 2017年04月16日 06:15 | |
| Messages (4) | |||
|---|---|---|---|
| msg291736 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) | Date: 2017年04月16日 06:12 | |
One of the most used by me option of the "perf timeit" subcommand is --duplicate. It duplicates statements to reduce the overhead of the loop. This is necessary when measure the time of very fast statements. Proposed patch adds this option for CLI of the timeit module. Similar feature already was proposed in issue21988, but it automatically duplicated statements if they executed too fast. This patch does this only on explicit request. And it affects only command-line interface. You need to duplicate statements manually when use programming interface. |
|||
| msg291771 - (view) | Author: Raymond Hettinger (rhettinger) * (Python committer) | Date: 2017年04月17日 00:47 | |
+1 I've long used this technique when timing fast statements. See https://code.activestate.com/recipes/577834 for an example. |
|||
| msg295317 - (view) | Author: STINNER Victor (vstinner) * (Python committer) | Date: 2017年06月07日 08:14 | |
About the command line interface, I would expect that "timeit -n 10 --duplicate 10 STMT" would run STMT 100 times. I chose this behaviour in perf timeit: http://perf.readthedocs.io/en/latest/cli.html#timeit-cmd Current behaviour chosen by Serhiy, -n3 --duplicate=3 runs STMT 3 times: $ ./python -m timeit --duplicate=3 -r 1 -n 3 'print("bla")' bla bla bla 3 loops, best of 1: 21.8 usec per loop |
|||
| msg295326 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) | Date: 2017年06月07日 09:56 | |
Ah, I even didn't know that "perf timeit" supports -n since it doesn't report the number of loops. And seems it runs the benchmark much more times, since even with -n1 it is slow. If the number of loops is determined automatically, it would do not matter. I choose the meaning of --duplicate so that it almost not affect the total time of the benchmarking. Larger value just decreases the overhead of the iteration. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:58:45 | admin | set | github: 74266 |
| 2022年03月16日 17:17:08 | serhiy.storchaka | set | status: open -> closed resolution: rejected stage: patch review -> resolved |
| 2017年06月07日 09:56:33 | serhiy.storchaka | set | messages: + msg295326 |
| 2017年06月07日 08:14:50 | vstinner | set | messages: + msg295317 |
| 2017年05月04日 05:49:43 | serhiy.storchaka | set | assignee: serhiy.storchaka |
| 2017年04月17日 02:47:45 | gvanrossum | set | nosy:
- gvanrossum, Guido.van.Rossum |
| 2017年04月17日 00:47:21 | rhettinger | set | messages: + msg291771 |
| 2017年04月16日 12:08:45 | arigo | set | nosy:
- arigo |
| 2017年04月16日 06:15:52 | serhiy.storchaka | set | pull_requests: + pull_request1290 |
| 2017年04月16日 06:12:44 | serhiy.storchaka | create | |