> >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 I > >sacrifize that edge. > > Yep it seems like some of these are things which a realpath() cache patch > would not address. As I mentioned earlier we should make your patch > available but I think it's a bad idea to have it in the default distro. > I suggest the following: > 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 more look to double check if there aren't > any checks they can possibly save without impairing functionality. > c) Create a new version of your patch based on (a) & (b) and make sure we > find an accessible place for it with the disclaimer. Maybe Steph can take > care of that. As I'm very interested in this patch and patches like this I send this reply to make a suggestion.
1) This patch can and will break some applications, the users needs to be aware of this. So a big warning needs to be shown to the user. 2) Application vendors should be able to advice their customers to tune PHP to run an application and the vendor will then say which patch you can safely run or not. So the patch should be available easily. 3) Having patches available means that they can be improved by many people and Rasmus doesn't need to maintain this, which means less work load on him. 4) Making the realpath() cache is a good thing, but it is not the same. So like winnie the pooh I would say yes, both please. 5) If we create a patch repository somewhere this would make the patches available, but it will be much more hazzle for the users - which is not good. If a user wants to use several patches from this repository he needs to download the patches verify that he has the correct version and also verify that one patch does not break another. The latter point can quickly be an issue since if you have a patch repository then it could be a pain to make sure that all patches are compatible with eachother. What about doing it similar to the way the Linux kernel does this. We could add --experimental compile options. E.g. --experimental- (or --non-standard- or another good indicating name for that matter ). So adding --exeprimental-minimize-statcall could enable this patch. After the build is done there should be a big fat warning about the different experimental patches with links to information about them. E.g. detailed information about what they will break. In phpinfo() it should also be a list with experimental options, mabye even in bold/red font to make it very clear. Atleast I find it simpler to advice e.g. a hosting company to enable --experimental--foo to boost performance rather than tell them to download, make sure you have the correct version and patch. And in the end it's the end users we would like to make things simpler for right? Atleast this is what I think about the matter. We would gladly spend the time eneded to make what I describe above. Cheers, -- Bård Farstad [EMAIL PROTECTED] | eZ systems | http://ez.no -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
