On Wed, 15 Sep 2004, Andrey Hristov wrote:
> > Patches are still a hassle to maintain, especially if you're mixing two
> > of them running it on the same code. THey also need updating often due
> > to changes in the distribution. Thinks like that are annoying, although
> > I don't see a better sol
Rasmus Lerdorf wrote:
> Derick and I are both deploying controlled code on a huge scale and
> turning off edge-case stuff we know we will never use can make a big
> difference. Even a 1 or 2 req/sec difference is significant when you
> serve up billions of pages a day. A good example of that is t
Can someone who has more configure knowledge than me volunteer to make our
build system use non-pic for Linux/FreeBSD ia32?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 15 Sep 2004, Zeev Suraski wrote:
> That's true, I did kind of forget about the other OS's out there, it's very
> easy to get used to the efficiency of Linux...
> It would be interesting to see how far the realpath cache can get you with
> this app. Can you share that standard benchmark of
Derick Rethans wrote:
On Wed, 15 Sep 2004, Zeev Suraski wrote:
[snip]
I *think* you agree with that, and that we're best off putting it in a
special location, maybe on php.net (if you disagree and I'm putting words
in your mouth, my apologies and I take it back).
Patches are still a hassle to mai
On Wed, 15 Sep 2004, Zeev Suraski wrote:
> That's true, I did kind of forget about the other OS's out there, it's very
> easy to get used to the efficiency of Linux...
> It would be interesting to see how far the realpath cache can get you with
> this app. Can you share that standard benchmark of
The 161->195 looked a bit high to me so I went back through my notes and
that is actually for the syscall patch plus the non-pic patch. I don't
have numbers for just the syscall patch against stock PHP handy, but I'll
see if I can get some time to run some.
-Rasmus
On Wed, 15 Sep 2004, Rasmus Le
At 17:46 15/09/2004, Rasmus Lerdorf wrote:
On Wed, 15 Sep 2004, Zeev Suraski wrote:
> Can you share with us what kind of performance increase (vs. the 'much
> inferior' realpath cache or even plain vanilla PHP) we're dealing with
> here? By the way, I can tell you that in real world applications w
At 09:05 AM 9/15/2004 +0200, Derick Rethans wrote:
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> At 10:52 AM 9/14/2004 -0700, Rasmus Lerdorf wrote:
> >The patch doesn't just address realpath though. We have a number of other
> >redundant/non-essential syscalls in the streams code, for example. And
>
On Wed, 15 Sep 2004, Zeev Suraski wrote:
> Can you share with us what kind of performance increase (vs. the 'much
> inferior' realpath cache or even plain vanilla PHP) we're dealing with
> here? By the way, I can tell you that in real world applications we did
> not manage to measure any performan
On Wed, 15 Sep 2004, Adam Maccabee Trachtenberg wrote:
> On Wed, 15 Sep 2004, Derick Rethans wrote:
>
> > There is also no reason why people would just enable this feature by
> > default if they have no clue what they are doing, we can add big
> > nice disclaimers around it.
>
> We see idiots subm
On Wed, 15 Sep 2004, Derick Rethans wrote:
> There is also no reason why people would just enable this feature by
> default if they have no clue what they are doing, we can add big
> nice disclaimers around it.
We see idiots submit bug reports with all sorts of configure options
they should never
At 10:03 15/09/2004, Derick Rethans wrote:
On Tue, 14 Sep 2004, Andrey Hristov wrote:
> Both points make sense. Just name the configure option well and put big
warnings there
> that when the option is switched on this _may_ lead to crashing
applications.
Nothing will crash, it's just that includ
Jan Schneider wrote:
> Zitat von Derick Rethans <[EMAIL PROTECTED]>:
>
>> On Tue, 14 Sep 2004, Andi Gutmans wrote:
>>
>>> a) I will try and send internals@ an updated version of the realpath()
>>> cache in the next few days. This should give a lot of bang for the buck
>>> because realpath() is prob
On Wed, 15 Sep 2004, Jan Schneider wrote:
> Why not keeping that patch (and others that might be worth it as well) in
> the php-src module, but really as a patch, not applied to the default
> distro? This way it's available at a single point, everyone having a
> tarball can apply it, and it still
Zitat von Derick Rethans <[EMAIL PROTECTED]>:
On Tue, 14 Sep 2004, Andi Gutmans wrote:
a) I will try and send internals@ an updated version of the realpath()
cache in the next few days. This should give a lot of bang for the buck
because realpath() is probably the suckiest system call in the startu
> >It's mostly just looking at the common path and watching the syscalls and
> >getting rid of anything that isn't logically needed to serve up a normal
> >PHP page. I understand that some of these checks are necessary for
> >edge-case things, but when an edge-case check slows down the common case
On Tue, 14 Sep 2004, Zeev Suraski wrote:
> I don't disagree that it can be useful. But such a feature should not come
> bundled as an option in PHP. The Right(tm) solution here is to provide the
> realpath cache, which will speed performance up without breaking
> compatibility, and hopefully we'
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> a) I will try and send internals@ an updated version of the realpath()
> cache in the next few days. This should give a lot of bang for the buck
> because realpath() is probably the suckiest system call in the startup.
> b) Maybe Wez & Sara can take one m
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> At 10:52 AM 9/14/2004 -0700, Rasmus Lerdorf wrote:
> >The patch doesn't just address realpath though. We have a number of other
> >redundant/non-essential syscalls in the streams code, for example. And
> >the realpath cache is still heavier than not wor
On Tue, 14 Sep 2004, Andrey Hristov wrote:
> Both points make sense. Just name the configure option well and put big warnings
> there
> that when the option is switched on this _may_ lead to crashing applications.
Nothing will crash, it's just that include_once might fail if you're
using two dif
Yeah I'll try and see what can be done. It might be a bit tricky because
TSRM doesn't "know" PHP but I think it can be solved.
Andi
At 04:33 PM 9/14/2004 -0700, Rasmus Lerdorf wrote:
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> a) I will try and send internals@ an updated version of the realpath()
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> a) I will try and send internals@ an updated version of the realpath()
> cache in the next few days. This should give a lot of bang for the buck
> because realpath() is probably the suckiest system call in the startup.
Make sure you update it to use the n
At 11:30 AM 9/14/2004 -0700, Rasmus Lerdorf wrote:
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> Can you describe the other non-essential syscalls? I want to be sure we
> really can't cover those (probably some of them we can't).
> As far as the realpath patch goes (which is probably the biggest probl
On Tue, 14 Sep 2004, Andi Gutmans wrote:
> Can you describe the other non-essential syscalls? I want to be sure we
> really can't cover those (probably some of them we can't).
> As far as the realpath patch goes (which is probably the biggest problem),
> I think that if we have the realpath cache i
At 10:52 AM 9/14/2004 -0700, Rasmus Lerdorf wrote:
The patch doesn't just address realpath though. We have a number of other
redundant/non-essential syscalls in the streams code, for example. And
the realpath cache is still heavier than not worrying about the full path
at all.
Can you describe th
The patch doesn't just address realpath though. We have a number of other
redundant/non-essential syscalls in the streams code, for example. And
the realpath cache is still heavier than not worrying about the full path
at all.
I do agree that however people get this patch, they need to understan
At 19:29 14/09/2004, Derick Rethans wrote:
> And yes, there is no doubt that this patch can critically alter the way
> PHP works and has the potential to break all sorts of stuff. Anything
> that relies on PHP knowing the full path will break. I had to fix both
> xdebug and APC, for example. At
Hey Derick and all,
As I mentioned in the past, I think solving it in a completely compatible
manner is the best way to go.
I sent out the realpath() cache patch which addresses the most problematic
file system issues (and if there are any other things we could probably
address too).
I think the
Derick Rethans wrote:
On Tue, 14 Sep 2004, Rasmus Lerdorf wrote:
That should have been a #ifndef SKIP_PATH_CHECKS there. And it is there
to get rid of a non-critical ftell().
Attached is the patch with this corrected, and corrected white space.
And yes, there is no doubt that this patch can cri
On Tue, 14 Sep 2004, Rasmus Lerdorf wrote:
> That should have been a #ifndef SKIP_PATH_CHECKS there. And it is there
> to get rid of a non-critical ftell().
Attached is the patch with this corrected, and corrected white space.
> And yes, there is no doubt that this patch can critically alter th
On Tue, 14 Sep 2004, Derick Rethans wrote:
> On Tue, 14 Sep 2004, Derick Rethans wrote:
>
> > On Tue, 14 Sep 2004, Wez Furlong wrote:
> >
> > > There's an #if 0 in there that probably shouldn't be
> >
> > Yeah, the whole stuff can be removed, as it's added in later again :)
> > I'll create a new p
I don't think we should have this patch in the distribution. It shouldn't
be that accessible as it has the potential to break behavior of both apps
and plugins. I think it belongs in a patches repository such as
http://www.zend.com/zend/week/pat/ (doesn't have to be that one in
particular, bu
To eliminate an fstat() most likely; it can stay, but it should
probably changed to #ifndef SKIP_PATH_CHECKS instead.
--Wez.
On Tue, 14 Sep 2004 14:50:09 +0200 (CEST), Derick Rethans
<[EMAIL PROTECTED]> wrote:
> On Tue, 14 Sep 2004, Derick Rethans wrote:
>
> > On Tue, 14 Sep 2004, Wez Furlong w
On Tue, 14 Sep 2004, Derick Rethans wrote:
> On Tue, 14 Sep 2004, Wez Furlong wrote:
>
> > There's an #if 0 in there that probably shouldn't be
>
> Yeah, the whole stuff can be removed, as it's added in later again :)
> I'll create a new patch for it here.
hmm, no, this was a different patch. No
On Tue, 14 Sep 2004, Wez Furlong wrote:
> There's an #if 0 in there that probably shouldn't be
Yeah, the whole stuff can be removed, as it's added in later again :)
I'll create a new patch for it here.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP
There's an #if 0 in there that probably shouldn't be
--Wez.
On Tue, 14 Sep 2004 14:10:52 +0200 (CEST), Derick Rethans
<[EMAIL PROTECTED]> wrote:
> Hei,
>
> This is Rasmus' patch including a configure option
> "--disable-path-normalization" to enable this patch. By default this
> option is of co
Hei,
This is Rasmus' patch including a configure option
"--disable-path-normalization" to enable this patch. By default this
option is of course turned off.
I am planning to commit this patch after 4.3.9 is released too, in case
there are no good objections.
Derick
--
Derick Rethans
http://der
38 matches
Mail list logo
