prev_tup with n parameter

this makes the usages of prev_tup approx 3 times faster
This commit is contained in:
Klaas van Schelven
2024-01-05 17:47:59 +01:00
parent 8728fbadc6
commit da04ebe6c7
4 changed files with 33 additions and 17 deletions

View File

@@ -1,16 +1,16 @@
## _prev_tup()
1_000 iterations of _prev_tup in 0.794ms. The main thing we care about is not this little
1_000 iterations of _prev_tup in 0.816ms. The main thing we care about is not this little
private helper though, but PeriodCounter.inc(). Let's test that next.
## PeriodCounter.inc()
1_000 iterations of PeriodCounter.inc() in 25.186ms. We care about evaluation of some event more though. Let's
1_000 iterations of PeriodCounter.inc() in 7.766ms. We care about evaluation of some event more though. Let's
test that next.
## PeriodCounter.inc()
1_000 iterations of PeriodCounter.inc() in 93.481ms. (when 3 event-listeners are active). I'm not sure exactly
1_000 iterations of PeriodCounter.inc() in 29.593ms. (when 3 event-listeners are active). I'm not sure exactly
what a good performance would be here, but I can say the following: this means when a 1,000 events happen in a second,
the period-counter uses up 10% of the budget. A first guess would be: this is good enough.
the period-counter uses up 3% of the budget. A first guess would be: this is good enough.

View File

@@ -106,7 +106,7 @@ def print_thoughts_about_event_evaluation():
1_000 iterations of PeriodCounter.inc() in {t.elapsed:.3f}ms. (when 3 event-listeners are active). I'm not sure exactly
what a good performance would be here, but I can say the following: this means when a 1,000 events happen in a second,
the period-counter uses up 10% of the budget. A first guess would be: this is good enough.""")
the period-counter uses up 3% of the budget. A first guess would be: this is good enough.""")
print_thoughts_about_prev_tup()