Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:13102
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: <internals@lists.php.net>
Date: Fri, 1 Oct 2004 11:49:22 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_002D_01C4A7AC.B16A3E40"
Thread-Index: AcSn512xhiDtkGgTSx+6Gy6QnZclVg==
Message-ID: <auto-000000442687@bobsilva.com>
Subject: [PATCH] Small ini file optimization
From: junkmail@bobsilva.com ("Robert Silva")

------=_NextPart_000_002D_01C4A7AC.B16A3E40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

During php_init_config() in php_ini.c, it currently loads environment
settings, (on windows, system directories and registry settings), binary
locations building the path to search for ini files.

If you specify -n on the command line, any code that would use these paths
are excluded so building the search path is all for not.

This patch saves quite a few system calls on windows and returns immediately
if -n has been specified. As best as I could tell, there would be no side
effects to this immediate return.

The changes are much smaller than the patch file due to some code
reformatting to maintain proper indentation.

Also, I noticed (on my system at least) that my windows directory was
searched 3 times for php.ini (which doesn't exist there). Would a little
caching mechanism for php_fopen_with_path, to not duplicate lookups be worth
it? Could it be designed in such a way that it would be faster than the stat
calls on the filesystem which may make use of disk cache.


Bob Silva

------=_NextPart_000_002D_01C4A7AC.B16A3E40--