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 performance gain from the realpath cache, even > though we measured 35% performance improvement in a synthetic test, and I > expect it to be quite similar with this patch. Before we introduce such a > big potential for breakage at the fingertips of every user, let's be sure > it's worth it.
It depends completely on your operating system. Benchmark an application on FreeBSD 4.x that has a lot of includes and you can't miss it. My standard benchmark, which doesn't actually do very many file ops went from 161 requests/second to 195 requests/second with this patch.
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?
On operating systems like Linux where syscalls are much lighter, you won't see anywhere near that. But you are still going to see a difference. If you couldn't measure a performance gain then it was lost in some serious other noise in your test. You will typically go from something like 120 stats, seeks and ftells down to 8 or 9 per request with the patch.
True, but the bottom line is that it wasn't noticeable in real world apps. It was lost in the noise, except the noise happened to be the application code itself (several apps we took as-is from the web). In a synthetic benchmark designed to measure just the performance of include()'s we measured a significant performance gain (~30%).
And by the way, include_once doesn't completely break.
[snip]
Yes, I would know that. But it breaks when it's most needed. In my experience the circumstances where it won't work properly are extremely common.
assuming file.inc is in 'dir'. And while that is significant, in deployments where you have full control over the code or the ability to just whack people and tell them not to do stupid stuff like that, it becomes a non-issue.
I don't see why you think this is 'stupid' (of course, when it's not done within the same file). Again, it's extremely common and actually the whole point behind include_once() .
I do agree that if you have centralized control over your code you can force people not to use it, but that can apply to just about any other feature in PHP. We can probably have some --disable-indirect-reference switch that might enable us to get an extra bit of performance, do we want to get into this business? I think not. Where do we draw the line?
The only way to draw it is to make it stupid-simple - if it allows users to selectively break (or alter) language functionality, it shouldn't be in the standard distribution. We have some old leftovers that don't follow these guidelines, but at least most of them are changeable in runtime (allowing for portable code), and all of them are at the very least can be configured in php.ini.
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).
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
