Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reworks the logic that checks for a winner. The new implementation checks after the end of each turn for the current player vs. the current implementation that loops over each player and checks if there's a winner.
Currently, the code loops over each player after each tick to determine if there's a winner. However, we can simply check if a player has won in their turn and store that information. This saves us from looping over the players after each tick which accounts for 5% of the runtime.
I found this by running a profiler and viewing the output through snakeviz:
We can notice a speed improvement in the overall runtime by running
time python3.9 play.py --num=1000
At commit
aa43d9
, the current head commit, my machine computes an average duration per game of 0.023s.In this commit, the average duration per game is 0.022s. Roughly a 4.5% improvement which correlates with the snakeviz graph.
The updated snakeviz profile shows that
![Screen Shot 2022-09-11 at 12 32 24 PM](https://user-images.githubusercontent.com/3202371/189538891-c9b3a23d-8d16-4a34-b22d-c681abe9ec8d.png)
winning_color
now accounts for only 0.21% of the runtime.