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 yours?
http://lerdorf.com/bench.tar It's actually a really crappy benchmark. When you profile it you see that it spends most of its time in var_dump(). I have been working on a better one that touches more of PHP evenly. > 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). I am not sure what the right solution is. I would like to see this patch and others like it be more visible in a way that when someone changes something that either affects the patch or perhaps even incorporates part of it, the patch is updated. I have a number of these sitting around that could be very useful but are somewhat limited in terms of their audience. We need some sort of better balance between safe vanilla code that runs everywhere for everyone and platform-specific or audience-specific stuff. 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 the pipe checks. I really don't need the ability to pipe scripts to be parsed by PHP and I am not willing to take the 2-syscall hit on every one of my requests to support this. Or the non-pic patch which we can't really deploy on a large scale because libtool is too stupid, but this patch provides an instant 10-20% performance increase on both ia32 FreeBSD and Linux while breaking ia64 Linux and AIX I think. Having the patches in the code itself could lead to an #if mess, especially since they may conflict. But on the other hand having them there would get people thinking about whether some of these things could be worked around or done in a better way and code changes would automatically be reflected in them. Perhaps a decent patch repository is the way to go. One that would keep track of patches by PHP version number and branches and periodically test-apply the patches against the trees and notify the patch maintainers of breakage. I don't really care about this particular patch, and I am nowhere near as keen as Derick on seeing a configure switch for it, what I would like to see is a system for dealing with these patches that would encourage more of them which in turn would lead to a lot of new ideas flowing into the project. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
