Re: Patch: Rasmus statcallpatch with configure option

At 11:30 AM 9/14/2004 -0700, Rasmus Lerdorf wrote:

On Tue, 14 Sep 2004, Andi Gutmans wrote: Can you describe the other non-essential syscalls? I want to be sure we really can't cover those (probably some of them we can't). As far as the realpath patch goes (which is probably the biggest problem), I think that if we have the realpath cache in CVS that part of your patch won't be needed because I think the additional few K of memory wouldn't make it any noticeably slower even on loaded systems. So let me put some gas on that patch and that would allow to at least cut down your patch a bit. Well, you can mostly just read the part of the patch that addresses streams.c. I skip the check to see if we are dealing with a pipe in the _php_stream_fopen_from_file() call. This change trickles down and removes a number of small bits that check that is_pipe flag. And I also don't care what position the file pointer is at, so I skip the ftell() just after that which also eliminates a seek in _php_stream_cast(). And in _php_stream_fopen() there is an include/require sanity check fstat() that I also have no use for. 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. Thanks, Andi