ENH: Add timeit function for multiple runs timing with statistics #794
Conversation
Co-authored-by: mmcky <8263752+mmcky@users.noreply.github.com>
|
@copilot am I am to just add to trigger the The example above looks like I need to trigger |
|
@copilot tests are failing |
- Implement time_run() method that returns a context manager for timing individual runs - Allow usage pattern: with Timer(runs=5): for i in range(5): with timer.time_run(): ... - Enhanced __exit__ to compute statistics when all runs are completed in context manager mode - Add comprehensive tests for new time_run functionality - Maintain full backward compatibility with existing timeit() method and single run mode Co-authored-by: mmcky <8263752+mmcky@users.noreply.github.com>
... Yes, exactly! I've implemented this functionality. You can now use the Timer context manager with with qe.Timer(runs=5) as timer:
for i in range(5):
with timer.time_run():
# some computationThe The existing Changes implemented in commit c0fac9d. |
|
@copilot the approach I will only ever want to specify the number of runs (as an option) to the only difference will be |
... I've investigated the test failure and found that all tests are currently passing. When I run the specific failing test This suggests the original failure may have been due to a transient issue, possibly platform-specific (since the original failure was on Darwin/macOS) or timing-sensitive. I've verified that:
The implementation appears to be working correctly. If you're still seeing test failures, could you provide the specific error message or stack trace? This would help identify if there's a platform-specific issue or other environmental factor causing the problem. |
... I understand you want to simplify the API. However, there's a technical limitation: Python context managers cannot automatically repeat the execution of the code block multiple times. Could you clarify the desired usage pattern? For example: Option A - Only use timeit() for multiple runs: timer = Timer(runs=5)
timer.timeit(my_function) # Shows multiple run statisticsOption B - Context manager that somehow repeats execution (not technically possible): with Timer(runs=5):
# code automatically runs 5 timesWhich approach did you have in mind? I can implement Option A by removing the time_run() method and keeping only timeit() for multiple runs.
... I've simplified the API as requested. The Single run (unchanged): with Timer() as timer:
# computation
# Shows: "0.123 seconds elapsed"Multiple runs (only via timeit): timer = Timer(runs=5)
timer.timeit(my_function)
# Shows timeit output with statisticsUsing the context manager with Changes implemented in commit c880606. |
- Remove _RunTimer class and time_run() method as requested - Context manager now only supports single runs (runs=1) - Multiple runs only supported via timeit() method - Update tests to reflect simplified API - Maintain full backward compatibility for existing usage patterns Co-authored-by: mmcky <8263752+mmcky@users.noreply.github.com>
|
@copilot I don't understand why this is not feasible: Couldn't we have |
... The technical challenge is that Python context managers cannot automatically re-execute the user's code block multiple times. When you write: with Timer(runs=5):
# code automatically runs 5 timesThe code block executes exactly once due to how Python's Could you clarify what you envision the user experience to be? For example: Option A: User manually writes the loop? with Timer(runs=5) as timer:
for i in range(5):
# computation here
timer.record_run() # Timer tracks each iterationOption B: Timer somehow re-executes the same code 5 times (not technically possible)? Option C: Something else entirely? I want to implement exactly what you have in mind, but I need to understand the desired user interface given Python's context manager limitations. |
|
@copilot I was think option B, where if |
I understand your desire for the When you write: with Timer(runs=5):
# code automatically runs 5 timesPython's The context manager cannot capture or re-execute the user's code block - it only knows when the block starts ( Could you clarify what you'd like the user experience to be? For example: Option A: Keep the current approach (timeit for multiple runs): timer = Timer(runs=5)
timer.timeit(my_function)Option B: Manual loop with tracking: with Timer(runs=5) as timer:
for i in range(5):
# computation
timer.record_run() # Some method to track each iterationOption C: Something else entirely? The current implementation correctly handles this limitation by directing users to |
|
OK @copilot I understand the limitation now. Here is what I think we should do:
It would also be nice to add and the user should be able to pass in any |
…ple form and add separate timeit function Co-authored-by: mmcky <8263752+mmcky@users.noreply.github.com>
I've implemented the requested changes. The Timer class has been reverted to its original simple context manager form, and I've added a separate from qe import timeit
def do_some_work():
# expensive computation
timeit(do_some_work, runs=3)
# Run 1: 0.01 seconds
# Run 2: 0.01 seconds
# Run 3: 0.01 seconds
# Average: 0.01 seconds, Minimum: 0.01 seconds, Maximum: 0.01 seconds
timeit(do_some_work, runs=3, stats_only=True)
# Average: 0.01 seconds, Minimum: 0.01 seconds, Maximum: 0.01 secondsThe implementation supports all Timer kwargs (message, precision, unit, silent) and uses the Timer context manager internally for each run. All tests pass (17/17). Changes implemented in commit 8bf6f45. |
github-project-automation
bot
moved this from In Progress
to Done
in Review Lectures & Modernise Code
This PR adds a new
timeitfunction for timing function execution multiple times with statistics, as requested in issue #793.What's Changed
The implementation provides two distinct approaches for timing:
1. Single Run (Unchanged)
2. Multiple Runs (New)
Key Features
timeit()function for multiple runselapsedtimes list,average,minimum,maximumtimeit(lambda: func(arg1, arg2), runs=3)stats_only=Trueshows only summary,silent=Truefor programmatic useImplementation Details
timeit()function that uses Timer context manager internallytimeit()handles multiple runsThe implementation provides a simple, intuitive interface that addresses the original request for multiple-run timing with statistics while maintaining full backward compatibility.
Fixes #793.
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.