Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!execu!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: Anything faster than stat(S)? need to determine File or Dir Message-ID: <17272@rpp386.cactus.org> Date: 11 Nov 89 18:06:52 GMT References: <152@norsat.UUCP> <2586@unisoft.UUCP> <15769@bloom-beacon.MIT.EDU> <17264@rpp386.cactus.org> <1989Nov11.154312.6675@virtech.uucp> Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 33 In article <1989Nov11.154312.6675@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >So you want to replace a single call to stat() with multiple calls to >access(). That doesn't make any sense since the major overhead to both >the stat and access system calls is that the path must be traversed and since >you are calling access twice, you have to traverse the path twice. The objective was to take advantage of path-name caching on BSD systems. Of course, if you know "/path/name" exists, you only need -one- call to access() with "/path/name/foo" and you save the mumbo-jumbo required to get data from kernel to user space. >stat() is the most effecient mechanism that can be used to obtain information >about a file system entry since it just looks up an inode and copies >the data to the user's data area. Probably true. Now, go off and actually run the benchmarks. =Always= question everything. On some machines copies from system to user address space are cheap. On others it can be =very= difficult. There is a big difference between a Vax where the supervisor and user have separate address spaces which can be directly addressed one from the other, and a PDP-11 where the supervisor and user occupy the same address space and have no [ MTPD and MFPD aren't implemented on all PDP-11 CPUs! ] easy way of communicating short of mapping memory all over God's creation. Anyway, it was only meant to stimulate discussion. The only portable and clean solution =is= to use stat(). I can't stand clever hacks, unless I write them myself ;-) -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of EMACS is ... InterNet: jfh@rpp386.cactus.org | ... EMACS makes a computer slow. UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--<><---