The irony of having to optimize echo
/bin/echo is running too slowly! echo does close to
nothing in terms of memory management, this is bad for the
mullocator, because I allocate currently about 70 VM pages
waiting for the onslaught of malloc calls. As these pages are
actually touched, this means that the kernel is zerofilling 280 MB,
which does take a perceptible amount of time, in the end echo
allocates like this (the + means
+ 40 + 44 + 8 + 72 + 40 + 40 + 40 + 131072 (131072)
Painfully enough, I can't satisfy the 32 pages request with my
already allocated pages, because it is too large (I reserve the 70
pages or so for smaller requests), which means more zerofilling.. I
have no idea, why
/bin/echo allocates 131072 bytes.
Might be fun to look into Darwin for that.