Performance of event-handling

performance/out/some_script.txt

@@ -1,14 +1,16 @@
 ## _prev_tup()
 
-1_000 iterations of _prev_tup in 1.608mss. The main thing we care about is not this little
+1_000 iterations of _prev_tup in 0.794ms. The main thing we care about is not this little
 private helper though, but PeriodCounter.inc(). Let's test that next.
 
-On testing: I noticed variations of a factor 2 even running these tests only a couple of times. For now I picked the
-slow results for a check in.
-
 
 ## PeriodCounter.inc()
 
-1_000 iterations of PeriodCounter.inc() in 82.716ms. We care about evaluation of some event more though. Let's
+1_000 iterations of PeriodCounter.inc() in 25.186ms. 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
+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.

performance/some_script.py

@@ -30,9 +30,6 @@ def print_thoughts_about_prev_tup():
 1_000 iterations of _prev_tup in {t.elapsed:.3f}ms. The main thing we care about is not this little
 private helper though, but PeriodCounter.inc(). Let's test that next.
 
-On testing: I noticed variations of a factor 2 even running these tests only a couple of times. For now I picked the
-slow results for a check in.
-
 """)
 
 
@@ -68,5 +65,50 @@ test that next.
 """)
 
 
+def print_thoughts_about_event_evaluation():
+    random.seed(42)
+
+    pc = PeriodCounter()
+
+    def noop():
+        pass
+
+    # let's add some event-listeners. These are chosen to match a typical setup of quota for a given issue or project
+    # (as we now believe such setups to be). i.e. a monthly maximum is 'distributed down' in such a way that the lower
+    # granularities are somewhat more than would be expected by simply dividing in equal parts. Rationale: we want to
+    # allow some burstyness, but we don't want to "eat up our budget" for a larger time-period in a single burst.
+    pc.add_event_listener("day",    30, 10_000, noop, noop, event_state=False)  # 1 month rolling window
+    pc.add_event_listener("hour",   24,  1_000, noop, noop, event_state=False)  # 1 day rolling window
+    pc.add_event_listener("minute", 60,    200, noop, noop, event_state=False)  # 1 hour rolling window
+
+    # make sure the pc has some data before we start. we pick a 1-month period to match the listeners in the above.
+    for point in buckets_to_points_in_time(
+        generate_bursty_data(num_buckets=350, expected_nr_of_bursts=10),
+        datetime(2021, 10, 15, tzinfo=timezone.utc),
+        datetime(2021, 11, 15, 10, 5, tzinfo=timezone.utc),
+        10_000,
+            ):
+
+        pc.inc(point)
+
+    # now we start the test: we generate a bursty data-set for a 1-day period, and see how long it takes to evaluate
+    points = buckets_to_points_in_time(
+        generate_bursty_data(num_buckets=25, expected_nr_of_bursts=5),
+        datetime(2021, 11, 15, 10, 5, tzinfo=timezone.utc),
+        datetime(2021, 11, 16, 10, 5, tzinfo=timezone.utc),
+        1000)
+
+    with passed_time() as t:
+        for point in points:
+            pc.inc(point)
+
+    print(f"""## PeriodCounter.inc()
+
+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.""")
+
+
 print_thoughts_about_prev_tup()
 print_thoughts_about_inc()
+print_thoughts_about_event_evaluation()