aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMattias Andrée <maandree@kth.se>2017-06-15 17:02:58 +0200
committerMattias Andrée <maandree@kth.se>2017-06-15 17:02:58 +0200
commitc893d4d94e49982664908001057d16a056a923d8 (patch)
treef2fb1f59ae651941a1c860c26254cf419894d837
parentm readme (diff)
downloadyes-silly-c893d4d94e49982664908001057d16a056a923d8.tar.gz
yes-silly-c893d4d94e49982664908001057d16a056a923d8.tar.bz2
yes-silly-c893d4d94e49982664908001057d16a056a923d8.tar.xz
m
Signed-off-by: Mattias Andrée <maandree@kth.se>
-rw-r--r--README15
1 files changed, 15 insertions, 0 deletions
diff --git a/README b/README
index 040182a..fb0401a 100644
--- a/README
+++ b/README
@@ -2,6 +2,21 @@ GNU yes(1) is not that fast!
This implementaion is not only about 8
times as fast[0], it uses half as much CPU.
+Note that this implementation is not even
+optimal, the overhead at the start can be
+reduced by creating a buffer as large as
+the pipe and fill that buffer and only do
+one write(2) or vmsplice(2) to the pipe.
+Speaking of this overhead, this implementation
+is completely useless[1] unless the other
+program is will even read {PIPE_BUF} bytes
+(4096 on Linux, 512 on POSIX). Therefore,
+this implementation of yes(1) is just silly
+and should not be used by anyone.
+
[0] On my computer. If you get different
results please leave a comment.
+
+[1] Has no benefits what so every in any
+ aspect at all.