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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
