Re: Performance degradation part 2 the module version

From: Date: Sun, 23 Feb 2003 21:41:01 +0000
Subject: Re: Performance degradation part 2 the module version
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-94511@lists.php.net to get a copy of this message
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.

« previous php.dev (#94511) next »