Re: Re: cvs: php4 /ext/standard file.c
| From: | Sterling Hughes | 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.