Liste des Groupes | Revenir à cu programmer |
Rainer Weikusat <rweikusat@talktalk.net> writes:scott@slp53.sl.home (Scott Lurndal) writes:>Rainer Weikusat <rweikusat@talktalk.net> writes:>scott@slp53.sl.home (Scott Lurndal) writes:Rainer Weikusat <rweikusat@talktalk.net> writes:Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
>>>>As far as I could determine, some sort of path searching has existed>
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.
There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.
The internet RTT from Reading/ UK to Dallas/ Texas is about
0.12s. That's fast enough that there's no noticeable latency in
interactive shell sessions. I doubt that many real-world NFS
installations span â…• of the planet and hence, the latencies certainly
ought to be a lot lower.
You seem to have have forgotten that the NFS server needs to
do a directory lookup on the file server, which adds to the R/T
latency, sometimes significantly on a busy filesystem.
Well, then, which is it? Local file system operations or network
latencies?
Clearly both factor into latency.
Local file system operations on a NFS server are no different>
from local file system operations on some other multi-user machine, eg,
the abovementioned PDP-11.
Clearly the PDP-11 cannot be rationally compared with a modern
lab with thousands of pooled servers sharing storage over NFS.
Les messages affichés proviennent d'usenet.