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 little unsure if we should apply equivalent changes to the branch
(given our release policy), but I share your concerns for performance.

Ilia and I have discussed implementing some kind of fstat cache for use
by the "plain file" streams.  However, we are nowhere near implementing
this, yet alone certifying it safe for inclusion in the branch.

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).

--Wez.

On Sun, 23 Feb 2003, Rasmus Lerdorf wrote:

> In 4.3 we have:
>
> _llseek(4, 0, [0], SEEK_CUR)            = 0 <0.000009>
> lseek(4, 0, SEEK_SET)                   = 0 <0.000009>
> brk(0)                                  = 0x81a8000 <0.000008>
> brk(0x81a9000)                          = 0x81a9000 <0.000011>
> ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffd190) = -1 ENOTTY (Inappropriate ioctl for 
> device) <0.000009>
> brk(0)                                  = 0x81a9000 <0.000007>
> brk(0x81aa000)                          = 0x81aa000 <0.000009>
> read(4, "<html>\n<body>\n<?\n\techo \"Hello Wo"..., 8192) = 58 <0.000016>
> read(4, "", 4096)                       = 0 <0.000008>
> read(4, "", 8192)                       = 0 <0.000009>
> ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffc150) = -1 ENOTTY (Inappropriate ioctl for 
> device) <0.000008>
> close(4)                                = 0 <0.000010>
> munmap(0x402ba000, 4096)                = 0 <0.000014>
>
> I really don't understand the SEEK_CUR there.  We're seeking forward 0
> bytes from the current location followed directly by a SEEK_SET back to 0?
> Is this streams overhead or something?  Wez?
>
> >From there on the requests are similar.  The alarm(0) calls right after
> alarm(300) could probably be skipped in both cases.
>
> Anyway, I will go after all these extra lstat/fstat calls and fix that,
> but I would appreciate some help with the setitimer() and weird seeking
> stuff.


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to