> I'm sure we can eliminate those seeks. Are there any other areas in the
> streams code that you can see that could do with a syscall tune-up?
Ok, found two more. In _php_stream_fopen() we fstat() the script to be
opened:
realpath = expand_filepath(filename, NULL TSRMLS_CC);
fp = fop
> Admittedly, when opening the file for the first time, we do not need to
> seek - so we can avoid it by passing a flag (OR'd with the REPORT_ERRORS
> flag).
>
> I'm sure we can eliminate those seeks. Are there any other areas in the
> streams code that you can see that could do with a syscall tu
On Mon, 24 Feb 2003, Rasmus Lerdorf wrote:
> if (stream) {
> if (self->is_pipe) {
> stream->flags |= PHP_STREAM_FLAG_NO_SEEK;
> } else {
> stream->position = ftell(file);
> }
> }
>
> We should be able to skip that ftell() call on a script or
On Sun, 23 Feb 2003, Wez Furlong wrote:
> This double seeking is most probably due to the fact that the stdio
> layer does one set of seeking, whereas streams needs to do another.
>
> This can be solved by moving away from using stdio for streams, and just
> using the "raw" descriptors instead. (
> Have you been testing PHP_4_3 from CVS or the actual 4.3.0 release?
> You might find the situation slightly better using the latest (I tidied
> up some seek related issues the other day).
The straces are from PHP_4_3 HEAD as of this morning.
I thought originally that these issues were just a ha
This double seeking is most probably due to the fact that the stdio
layer does one set of seeking, whereas streams needs to do another.
This can be solved by moving away from using stdio for streams, and just
using the "raw" descriptors instead. (already made a start on this in
PHP 5).
I'm a lit
Rasmus Lerdorf wrote:
On Sun, 23 Feb 2003, Shane Caraveo wrote:
CGI, right? Part of this may be from the path_info handling I've added.
The extra realpath() and fstat() calls are not cgi specific, so if what
you added only affects cgi, then that isn't the big problem.
-Rasmus
ok, it's only i
On Sun, 23 Feb 2003, Shane Caraveo wrote:
> Rasmus Lerdorf wrote:
> > So, I am just starting out down the path to figure out why PHP 4.3 has
> > gotten so much slower than 4.2. "strace -c" provides the first clue. A
> > straight "./configure --enable-inline-optimization && make" command-line
> >
Rasmus Lerdorf wrote:
So, I am just starting out down the path to figure out why PHP 4.3 has
gotten so much slower than 4.2. "strace -c" provides the first clue. A
straight "./configure --enable-inline-optimization && make" command-line
build for 4.2, 4.3 and 5.0 run on a simple hello world scrip
Rasmus Lerdorf wrote:
>
> That's true, but in threaded mode we don't do the chdir() at all. This is
> specifically for non-threaded.
>
Gotcha... didn't realize you were referring to non-t'ed only.
--
===
Jim Jagielski
On Sun, 23 Feb 2003, Jim Jagielski wrote:
> Rasmus Lerdorf wrote:
> >
> > Even in 4.2, I think we can optimize it. Assuming chdir() doesn't return
> > an error, we shouldn't need that second getpwd() call since we just did
> > the chdir() and we should know where we are.
> >
>
> Not necessarily..
Rasmus Lerdorf wrote:
>
> Even in 4.2, I think we can optimize it. Assuming chdir() doesn't return
> an error, we shouldn't need that second getpwd() call since we just did
> the chdir() and we should know where we are.
>
Not necessarily... In a threaded environment, if threadA does
chdir(/tmp)
A little bit harder to get clean output on this one. The numbers in the
<>'s are the times for the system call. Here is a 4.2 hello world
request:
accept(24, {sin_family=AF_INET, sin_port=htons(57198),
sin_addr=inet_addr("10.0.1.254")}}, [16]) = 3 <4.035087>
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x
On Sun, 23 Feb 2003, Stanislav Malyshev wrote:
> RL>> So, obviously these opens don't really affect the module version
> RL>> since they only happen on startup, but they still don't seem right.
> RL>> I understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini?
> RL>> Looks like a missing check
RL>> So, obviously these opens don't really affect the module version
RL>> since they only happen on startup, but they still don't seem right.
RL>> I understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini?
RL>> Looks like a missing check there.
If this is only for CGI/startup, it is indee
So, obviously these opens don't really affect the module version since
they only happen on startup, but they still don't seem right. I
understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini? Looks like a
missing check there.
I just recognized these yesturday, too and was thinking the same
So, I am just starting out down the path to figure out why PHP 4.3 has
gotten so much slower than 4.2. "strace -c" provides the first clue. A
straight "./configure --enable-inline-optimization && make" command-line
build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that
we have
17 matches
Mail list logo
