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 different paths to include it.
I apologize if I didn't make it clear that I did not refer to C level crashes (segfaults) but rather application crashes ('function X redeclared', etc., or apps breaking in a variety of interesting ways - that's a crash all the same).
include_once() breaking is a insanely high price to pay that mustn't be taken lightly. It won't be the only thing, anything that relies on opened_path being accurate will not work properly, include_once() is one example, code that uses __FILE__ and php.ini's location in phpinfo() are two others I can think of off hand. There was life before opened_path, and it wasn't pretty - we introduced it for a reason - it was needed in all sorts of places.
No big deal and easy to fix too IF you need this kind of performance increase. Big warnings is fine with me :)
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.
Again, my view is that it's exactly in the opposite direction of where we've been pushing PHP in the last few years, striving for maximum compatibility even when it comes at a cost. Unless the cost is unbearable (waiting for the numbers) I see no reason to deviate from these guidelines, even if a few people find it interesting. It's the millions who don't that we should think about.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
