Re: [9fans] blanks in file names

[Geoff Collyer <geoff@collyer.net>]

My apologies for dragging this out, but I think this gets to the heart
of the matter.

The cost of strlen doesn't matter, it really doesn't matter.  I can't
recall seeing a real-life program where the cost of strlen was more
than trivia.

A quick comparison on Plan 9 shows that strlen runs at 19 times the
speed of DES, using the same 64-byte string as input each time, which
is almost certainly longer than the average string.  DES is really
slow, by design; it's not just a question of a few more memory
accesses; it's just hard to do the bit-swizzling quickly in software
(though it can be done relatively quickly in hardware).

One of the big achievements of Unix was to get people to stop worrying
about the microseconds and look at the slightly larger picture of what
could be done if your first concern were not microseconds, and that
was a quarter-century ago!  With processor cycles being so cheap and
available now, it's generally not worth worrying about expenses until
they cause a real (measurable, reproducible) problem.  Proposals based
on supposedly greater efficiency for a new open(2) interface are not
worth considering, particularly when open's efficiency isn't currently
a problem, and the new interface is ugly, incompatible with the
existing clean and simple one, and purports to solve non-problems like
allowing NUL and slash in file name components.


One downside of APE is that it's made some people think of Plan 9 as
Just Another Goddamned Unix Implementation.  If you're not interested
in exploring what's new in Plan 9, and are offended that realloc isn't
provably optimal or that GNU configure doesn't just run out the box,
why are you using Plan 9?  FreeBSD, OpenBSD, NetBSD and Linux are all
available at no monetary cost.