Re: Re: cvs: php4 /ext/standard file.c

From: Date: Tue, 08 Apr 2003 23:01:39 +0000
Subject: Re: Re: cvs: php4 /ext/standard file.c
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-814@lists.php.net to get a copy of this message
On Tue, 2003-04-08 at 18:20, Rasmus Lerdorf wrote: > > I had the same reaction when I saw this but ultimately decided to leave it > > in. > > > > (A) Hopefully sterling had a reason for putting it in in the first place :) > > Don't be too sure. copy & paste. > > > (B) include_path typically starts with a '.' making this a non-issue. > > Many places this is not the case as it is actually a rather nasty > performance problem. For really performance-sensitive sites you should be > using: include './foo.inc'; if you want to include from the current dir > and let the include_path pick up any of the non-relative includes, but > make sure that the first path in your include_path is where the bulk of > these will come from. It is very common to have a shared code library > stored somewhere and to point your include_path at that. eg. PEAR. If > you put '.' first in your include_path then every single include for a > file in that library is going to do a useless stat() in the current > directory first. > > > (C) fopen($filename, 'w', true) is possible and can cause exactly the same > > potential problem anyway. > > That's true, and I'd be inclined to turn off include_path on a 'w' or > 'w+', but then we'd be parsing the mode and that's pretty nasty, so I > guess I am +0 on this as well. > i don't really see the point of using include_path in the first place. -Sterling -- -- "That stuff's easy compared to installing horde :)" - Alan Knowles, In response to my applause for creating a LALR parser for PHP.

« previous php.internals (#814) next »