Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-28 Thread Rasmus Lerdorf
> Don't you have any FreeBSD kernel hackers in Y!? You could probably > convince/bully one of them to fix it, that's what we always do with ours > here ;-) Turns out that one of the problems is that the standard 0x80 way of doing a syscall is rather slow on the P4 chip. P3 and Athlon chips are

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-26 Thread Stanislav Malyshev
RL>> Well, they require us to be able to uniquely identify a file, they do RL>> not necessarily require us to know the canonical filename. This RL>> could be done in a single stat where we grab the device number and RL>> inode. And if inode of the file changes? Files are still identifies (at leas

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread George Schlossnagle
Perhaps make it configurable because on Linux there already is a dcache right in the kernel which is likely to be faster than anything we can do. On linux you still have to make all those stat calls (they just return fast). A hashlookup inside TSRM will almost certainly return much faster. A

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Rasmus Lerdorf
> I think the best solution to this problem, without breaking functionality, > is to use a cache for realpath() in virtual_file_ex(). > This should solve the performance problems and not effect BC at all. As > TSRM always passes a full path to the realpath() call there, it should > always work.

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread George Schlossnagle
I like this solution. On Saturday, January 25, 2003, at 09:08 AM, Andi Gutmans wrote: Hi, I think the best solution to this problem, without breaking functionality, is to use a cache for realpath() in virtual_file_ex(). -- PHP Development Mailing List To unsubscribe, v

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Rasmus Lerdorf
> >Another idea would be to try to streamline the normal case for an absolute > >pathname. How about doing a readlink() on it. If that tells us that it > >is a link, then we know there is something funky and we can do a realpath, > >otherwise we just assume it is canonical assuming there are no .

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Andi Gutmans
Hi, I think the best solution to this problem, without breaking functionality, is to use a cache for realpath() in virtual_file_ex(). This should solve the performance problems and not effect BC at all. As TSRM always passes a full path to the realpath() call there, it should always work. Andi

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Marcus Börger
At 13:30 25.01.2003, Sebastian Bergmann wrote: Sascha Schumann wrote: > The question here is whether it's worthwhile to optimize for > the case where you have 30+ includes per page. Is it that > common? I think this is very common, for example with OOP applications that usually have one file

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Sebastian Bergmann
Sascha Schumann wrote: > The question here is whether it's worthwhile to optimize for > the case where you have 30+ includes per page. Is it that > common? I think this is very common, for example with OOP applications that usually have one file per class. -- Sebastian Bergmann http://s

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Miham KEREKES
> > That said, we could possibly have a fast mode and use fstat() to get some > > device information on the open file. I am worried about functionality > > though. I'm not sure it's worth breaking. > > The question here is whether it's worthwhile to optimize for > the case where you have 30+ inclu

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Andi Gutmans
At 02:30 AM 1/25/2003 -0800, Rasmus Lerdorf wrote: > That said, we could possibly have a fast mode and use fstat() to get some > device information on the open file. I am worried about functionality > though. I'm not sure it's worth breaking. Yes, fstat() is fast. And perhaps it isn't worth brea

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Rasmus Lerdorf
> The question here is whether it's worthwhile to optimize for > the case where you have 30+ includes per page. Is it that > common? In my particular case just 2 or 3 includes puts me over the top actually. stat() is amazingly slow on freebsd and having 3 includes of files in a dir

RE: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Lukas Smith
> -Original Message- > From: George Schlossnagle [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 25, 2003 5:28 AM > To: Rasmus Lerdorf > Cc: [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] Reducing the number of system calls for includes > > On Friday, Januar

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Rasmus Lerdorf
> That said, we could possibly have a fast mode and use fstat() to get some > device information on the open file. I am worried about functionality > though. I'm not sure it's worth breaking. Yes, fstat() is fast. And perhaps it isn't worth breaking functionality across the board, but in my pa

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Sascha Schumann
> That said, we could possibly have a fast mode and use fstat() to get some > device information on the open file. I am worried about functionality > though. I'm not sure it's worth breaking. The question here is whether it's worthwhile to optimize for the case where you have 30+ includes

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Andi Gutmans
At 04:51 PM 1/24/2003 -0800, Rasmus Lerdorf wrote: Which broken systems? Certainly not on FreeBSD or Linux. A little test: stat("/home/rasmus/foo/u2.inc",&sb); That ends up doing just a single stat on FreeBSD: stat("/home/rasmus/foo/u2.inc",0x9fbffa0c) = 0 (0x0) and on Linux: st

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-25 Thread Rasmus Lerdorf
> Weird. That was totally contrary to the way I remember it working. In > trying to figure out why I remembered incorrectly, I realized the > reason why you (in general) want to resolve the path to a canonical > path is that you can seriously break include_once and require_once if > you dont.

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread George Schlossnagle
On Friday, January 24, 2003, at 10:19 PM, Rasmus Lerdorf wrote: Eliminating realpath for fully qualified paths make sense to me. But... don't you Y! guys use php-a? Shouldn't this hide that overhead completely from you by completely eliminating all the stats on a require/include after the in

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Alan Knowles
Apart from tidying up the include stuff.. - for this specific case, is it worth cosidering precompiling all the files into a single bytecode file?, thats what bcompiler ends up doing for classes.. etc. then manually indicate that you want to recompile the bundle, I'm guessing the actual PHP cod

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Rasmus Lerdorf
> Eliminating realpath for fully qualified paths make sense to me. > > But... don't you Y! guys use php-a? Shouldn't this hide that overhead > completely from you by completely eliminating all the stats on a > require/include after the initial compilation? Or is this just a It doesn't elimi

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread George Schlossnagle
Eliminating realpath for fully qualified paths make sense to me. But... don't you Y! guys use php-a? Shouldn't this hide that overhead completely from you by completely eliminating all the stats on a require/include after the initial compilation? Or is this just a 'greater good' optimization

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Rasmus Lerdorf
On Sat, 25 Jan 2003, Andi Gutmans wrote: > At 04:32 PM 1/24/2003 -0800, Rasmus Lerdorf wrote: > > > I can't really think of any way of getting around this. include_once() and > > > require_once() are basic language constructs and they require this. > > > >Well, they require us to be able to uniquel

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Andi Gutmans
At 02:42 AM 1/25/2003 +0200, Andi Gutmans wrote: At 04:32 PM 1/24/2003 -0800, Rasmus Lerdorf wrote: > I can't really think of any way of getting around this. include_once() and > require_once() are basic language constructs and they require this. Well, they require us to be able to uniquely iden

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Andi Gutmans
At 04:32 PM 1/24/2003 -0800, Rasmus Lerdorf wrote: > I can't really think of any way of getting around this. include_once() and > require_once() are basic language constructs and they require this. Well, they require us to be able to uniquely identify a file, they do not necessarily require us to

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Rasmus Lerdorf
> I can't really think of any way of getting around this. include_once() and > require_once() are basic language constructs and they require this. Well, they require us to be able to uniquely identify a file, they do not necessarily require us to know the canonical filename. This could be done

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Rasmus Lerdorf
> >As for numbers, I basically doubled the req/sec rate of a box by > >eliminating a bunch of system calls caused by include_path and > >open_basedir stat'ing, so in my particular situation here eliminating as > >many syscalls as I can is having a direct effect. > > What OS are you running on? Are

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Andi Gutmans
At 04:06 PM 1/24/2003 -0800, Rasmus Lerdorf wrote: > 5. Looking at Linux's syscall implementation and implementing > the good ideas in FreeBSD. Well yes, but fixing the os is pretty drastic. For now I will be patching things here to short-circuit all that stuff, but I think it is also so

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Andi Gutmans
I can't really think of any way of getting around this. include_once() and require_once() are basic language constructs and they require this. There is no way I can think of to cache these results because they often depend on include_path and cwd which might change. Yes, we could try and think o

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Sascha Schumann
> Well, take an app that has 30 includes in a directory 5 levels deep. > Just the realpath() call is going to do 180 stats every time that script > is hit. Not sure how that wouldn't show up on the radar regardless of the > OS. You probably don't have anything that has 30 includes, but people out

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Rasmus Lerdorf
On Sat, 25 Jan 2003, Sascha Schumann wrote: > > files list. It's handy and nice to normalize the path here, but it is > > really really expensive! > > ..only on systems with ultra slow syscall setup procedures > (e.g. Solaris) or lack of directory cache. > > > Due to our current impleme

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Stig S. Bakken
On Sat, 2003-01-25 at 00:17, Rasmus Lerdorf wrote: > Take this script: > > > > So, a simple include with an absolute pathname to avoid any include_path > searching and all safe_mode and open_basedir checking turned off. The > latter of course being an absolute killer. We still need a lot of

Re: [PHP-DEV] Reducing the number of system calls for includes

2003-01-24 Thread Sascha Schumann
> files list. It's handy and nice to normalize the path here, but it is > really really expensive! ..only on systems with ultra slow syscall setup procedures (e.g. Solaris) or lack of directory cache. > Due to our current implementation, if you have a lot of includes, you > really should