Re: Patch: Rasmus statcallpatch with configure option

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 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 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. > > 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. > > And by the way, include_once doesn't completely break. It will still > catch multiple includes of the same path which is usually what people are > interested in. It just won't catch something like: > > include_once 'file.inc'; > include_once '../dir/file.inc'; > > 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. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >