@@ -19,7 +19,38 @@ Finally, you can compare the performance of the two versions of `seq`
1919by running, for example,
2020
2121``` shell
22- hyperfine " seq 1000000 " " target/release/seq 1000000"
22+ hyperfine -L seq seq, target/release/seq " {seq} 1000000"
2323```
2424
25+ ## Interesting test cases
26+
27+ Performance characteristics may vary a lot depending on the parameters,
28+ and if custom formatting is required. In particular, it does appear
29+ that the GNU implementation is heavily optimized for positive integer
30+ outputs (which is probably the most common use case for ` seq ` ).
31+
32+ Specifying a format or fixed width will slow down the
33+ execution a lot (~ 15-20 times on GNU ` seq ` ):
34+ ``` shell
35+ hyperfine -L seq seq,target/release/seq " {seq} -f%g 1000000"
36+ hyperfine -L seq seq,target/release/seq " {seq} -w 1000000"
37+ ```
38+
39+ Floating point increments, or any negative bound, also degrades the
40+ performance (~ 10-15 times on GNU ` seq ` ):
41+ ``` shell
42+ hyperfine -L seq seq,./target/release/seq " {seq} 0 0.000001 1"
43+ hyperfine -L seq seq,./target/release/seq " {seq} -100 1 1000000"
44+ ```
45+
46+ ## Optimizations
47+
48+ ### Buffering stdout
49+
50+ The original ` uutils ` implementation of ` seq ` did unbuffered writes
51+ to stdout, causing a large number of system calls (and therefore a large amount
52+ of system time). Simply wrapping ` stdout ` in a ` BufWriter ` increased performance
53+ by about 2 times for a floating point increment test case, leading to similar
54+ performance compared with GNU ` seq ` .
55+
2556[ 0 ] : https://github.com/sharkdp/hyperfine
0 commit comments