From afe00576b36db990de1e35fe69c3e687fcd60a68 Mon Sep 17 00:00:00 2001
From: Valentin Trophime <valentin.trophime@inria.fr>
Date: Fri, 8 Nov 2024 15:45:33 +0100
Subject: [PATCH] update readme with alignment note and Criterion

---
 README.md | 34 +++++++---------------------------
 1 file changed, 7 insertions(+), 27 deletions(-)

diff --git a/README.md b/README.md
index b885ca5..2d5b43c 100644
--- a/README.md
+++ b/README.md
@@ -9,25 +9,8 @@ It provides the `PreemptiveIterator` trait implemented for all standard Rust
 types implementing `core::iter::Iterator`. For the moment our trait provide only
 `fold, for_each` equivalent.
 
-## Overhead measurement
-
-There is an example in `examples/overhead.rs` you can try it with the following
-command :
-
-```bash
-cargo run --release --example overhead -- --reactivity-us 100 --n-iter 1000 --duration-us 10
-```
-
-The arguments are :
-
-- The number of iteration that you will perform.
-- Duration is the time it takes for each iteration to perform.
-- Reactivity is the targeted duration (in microseconds) between each
-  `yield_now().await` inserted by our iterator.
-
-Typical overhead values is between 0 and 2% at max for large number of
-iteration. The bad overhead is about 30% and happens when using few iterations
-(<50) with short duration tasks (< 10 μs).
+Typical overhead values is between 1 and 5%. Worst case around 30% and happens
+when using few iterations (<100) with short duration tasks (< 10 ns).
 
 ## TODO :
 
@@ -45,7 +28,11 @@ Reduce the Overhead for the worst cases, there are some ideas :
   don't do any call to `elapsed` the overhead is still of approximately 10% on
   the worst cases. This approach could help us to decrease this overhead.
 
-  - Split at seems worst, why ?
+- Criterion helps reduce benchmarking weirdness but still need to run bench
+  with:
+  `RUSTFLAGS="-C llvm-args=-align-all-functions=6 -C llvm-args=-align-all-nofallthru-blocks=6" cargo bench`
+  To reduce impact of alignment.
+
   - With optimization for size ?
   - Try various block size policies:
     - Adapt grow rate for exponential grows up with information from measured
@@ -62,10 +49,3 @@ More functions in API:
 - `ge, gt, le, lt, eq, ne` ?
 - `min, max, min_by, max_by, min_by_key, max_by_key` ?
 - `product, sum, reduce` ?
-
-Micro benchmark measurement weirdness:
-
-- Preemptive2 seems stable around 16% overhead in release and release-with-debug
-- Preemptive is unstable 3% in release and 45% in release-with-debug
-- TODO: keep only the Preemptive1 and try with/without debug, look and compare
-  asm maybe insert a call to a function with inline never to compare more easily
-- 
GitLab