[PHP-DEV] Re: 5.3 Release Planning
Hi, On Thu, 2008-03-06 at 20:43 -0600, Gregory Beaver wrote: Just a quick note: I'd like to consider another possible approach, having pecl/phar synced from stable pecl release. Yes, that's what I'd like, too. Te problem there is that developers using CVS checkouts should get a CVS checkout f it, too so it's being tested and can be fixed if needed. And if you read my mail you see that I mentioned doing it during buildconf, which is better than configure, I think ;-) I am also fine with symlinking until this can be perfected, as it is just an idea to be implemented right now. right. /me has no powers for actually doing that. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
i just hope the issue described in http://www.mail-archive.com/internals@lists.php.net/msg32601.html will be resolved before 5.3 is out. it is the only problem that breaks opcode cacher support as far as i can see by now. e.g.: with this problem fixed, all test cases will pass when XCache is enabled but not without fixed -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 07.03.2008 05:43, Gregory Beaver wrote: Just a quick note: I'd like to consider another possible approach, having pecl/phar synced from stable pecl release. I'm not sure it's good idea. IMO it should go trough much more thorough testing to be included into the core. And I'm still not convinced we should include any PECL extensions in the core, I believe it should go the other way round. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 3/7/08, Antony Dovgal [EMAIL PROTECTED] wrote: On 07.03.2008 05:43, Gregory Beaver wrote: Just a quick note: I'd like to consider another possible approach, having pecl/phar synced from stable pecl release. I'm not sure it's good idea. IMO it should go trough much more thorough testing to be included into the core. And I'm still not convinced we should include any PECL extensions in the core, I believe it should go the other way round. it would be better to say not in core, but in official distribution until there is convenient cross-platform of installing extensions from pecl, important ones should be included in distribution -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 07.03.2008 12:32, Alexey Zakhlestin wrote: I'm not sure it's good idea. IMO it should go trough much more thorough testing to be included into the core. And I'm still not convinced we should include any PECL extensions in the core, I believe it should go the other way round. it would be better to say not in core, but in official distribution PECL is officially distributed either. What I mean by the core is ext/ subdirectory of the sources tarball. until there is convenient cross-platform of installing extensions from pecl, important ones should be included in distribution Well, lets make it convenient then. Including everything into the core is not a solution. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for opcode caches
Hi,
The attached patch for PHP_5_3 is going to provide general solution to
control some aspects of PHP compilation. It is absolutely necessary for
all opcode caches to make cached scripts work exactly in the same way as
non-cached.
The problem occurs because early binding of inherited classes is not
possible for cached scripts. As result inheritance is handled in
run-time and classes might be created in wrong order. Most opcode caches
do some tricks to resolve this issue, but all of them fail to do it
right way.
The patch introduces CG(compiler_options), which is a set of compiler
flags that can be used by some extensions as opcode caches and
debuggers. Such flags change the process of compilation a bit.
For example to solve inherence early binding problem the opcode cache
need to compile file with additional flags
extension_compile_file() {
...
orig_compiler_options = CG(compiler_options);
CG(compiler_options) |= ZEND_COMPILE_IGNORE_INTERNAL_CLASSES |
ZEND_COMPILE_DELAYED_BINDING;
orig_compile_file();
CG(compiler_options) = orig_compiler_options;
...
}
And then during restoration from cache call
zend_do_delayed_early_binding().
This way even with cache all classes will be created exactly in the same
order.
The same CG(compiler_options) might be used to change other aspects of
compilation in the future.
The patch also optimizes ZEND_FETCH_CLASS+ZEND_ADD_INTERFACE opcodes
into single ZEND_ADD_INTERFACE, and makes verification of abstract
classes with interfaces only once.
I'm going to commit the patch on Monday or Tuesday.
Thanks. Dmitry.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for opcode caches
On Fri, 7 Mar 2008, Dmitry Stogov wrote: The attached patch for PHP_5_3 is going to provide general solution to control some aspects of PHP compilation. It is absolutely necessary for all opcode caches to make cached scripts work exactly in the same way as non-cached. There's no attached patch. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.3 Release Planning
The patch for this issue is sent to @internals. It will be probably commited on next week. Please try to play with it. Thanks. Dmitry, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of phpxcache Sent: Friday, March 07, 2008 12:27 PM To: Johannes Schluter Cc: PHP Internals List Subject: Re: [PHP-DEV] 5.3 Release Planning i just hope the issue described in http://www.mail-archive.com/internals@lists.php.net/msg32601.h tml will be resolved before 5.3 is out. it is the only problem that breaks opcode cacher support as far as i can see by now. e.g.: with this problem fixed, all test cases will pass when XCache is enabled but not without fixed -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Release Planning
gotcha, i'll check it within 24hours thanks for your great work -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
Hi Tony, Well, lets make it convenient then. Including everything into the core is not a solution. You seem to have missed an entire thread on the subject, along with the conclusion that the mechanisms for really doing a good job on this can't sanely be in place before 5.3.0 is released. They will need thorough testing before we start moving stuff out of core, and there just isn't time for that. It's more likely to be 5.4 before we can call it 'reliable'. What Greg's suggesting is that if phar goes into the distro, it can act as an early live test subject. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 07.03.2008 16:09, Steph Fox wrote: Hi Tony, Well, lets make it convenient then. Including everything into the core is not a solution. You seem to have missed an entire thread on the subject, along with the conclusion that the mechanisms for really doing a good job on this can't sanely be in place before 5.3.0 is released. They will need thorough testing before we start moving stuff out of core, and there just isn't time for that. It's more likely to be 5.4 before we can call it 'reliable'. The very same could be said about phar. What Greg's suggesting is that if phar goes into the distro, it can act as an early live test subject. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
The very same could be said about phar. It's going through a final wave of intensive development that *adds* to existing features; the core functionality's solid, and has been for some time. Given the end of April 'freeze', we're at least 2 months away from a 5.3 release. Assuming Greg's include patch or something akin to it is accepted into 5.3, all of that is fine-tuning time. What Greg's suggesting is that if phar goes into the distro, it can act as an early live test subject. - Steph -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
Antony Dovgal wrote: On 07.03.2008 05:43, Gregory Beaver wrote: Just a quick note: I'd like to consider another possible approach, having pecl/phar synced from stable pecl release. I'm not sure it's good idea. IMO it should go trough much more thorough testing to be included into the core. Hi, I wholeheartedly agree that phar needs more testing. I also think some other areas of php could have used more testing, such as the serious issues I found in zlib stream filters, but they were useful for years even with edge case flaws. Areas that I know phar needs work: * big-endian like PPC tar/zip support is incomplete, I need to write the simple byte order reversal that will complete this, and add the same compiler flags to the tar struct that we use on zip structs. This is an easy fix. * finishing up include_path support for streams. Other threads address this issue. This will remove the need for most of the proposed magic in pecl/phar/TODO. * ensuring full code coverage of tests, we're currently at about 68-70% * finishing up Steph's work on data-only tar/zip support (non-executable tar/zip read/write) * 2 open bugs at pecl.php.net * more hammering should be done on the web front controller to ensure edge cases have been considered Areas of phar that are rock-solid: * phar stream read/write * file format support for the 3 file formats read/write * anything else not yet mentioned. I expect to be able to wrap up the issues listed very quickly. Tony has been fantastic at finding memleaks/segfaults as new features are added, and we welcome the minutest scrutiny. And I'm still not convinced we should include any PECL extensions in the core, I believe it should go the other way round. This is secondary, but I'm proposing using phar to test the mechanism that will allow ext/ to migrate to pecl/ and still work as it did in ext/ Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Release Planning
On 07.03.2008 18:15, Gregory Beaver wrote: I wholeheartedly agree that phar needs more testing. I also think some other areas of php could have used more testing Undoubtedly. And I'm still not convinced we should include any PECL extensions in the core, I believe it should go the other way round. This is secondary, but I'm proposing using phar to test the mechanism that will allow ext/ to migrate to pecl/ and still work as it did in ext/ Ok, here I guess I should and read that thread Steph mentioned.. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fix for #39018 (suppressing error messages)
Hello, no reply means no! don't touch. ? Thanks. 2008/3/3, Felipe Pena [EMAIL PROTECTED]: Hello developers, I made a patch for the bug#39018: $x = 'test'; @$x[4] == 'a'; (@$x[4]) == 'a'; (@($x[4])) == 'a'; @($x[4]) == 'a'; $foo = 'test'; $x = @$foo[6]; Actually, all cases above shows E_NOTICE. With the patch, E_NOTICE is not showed. Patches: [5.3] http://felipe.ath.cx/diff/bug39018.diff [HEAD] http://felipe.ath.cx/diff/bug39018-HEAD.diff However, this patch breaks one test in Zend/tests/, because of an E_NOTICE: --TEST-- Bug #39304 (Segmentation fault with list unpacking of string offset) --FILE-- ?php $s = ; list($a, $b) = $s[0]; ? --EXPECTF-- Fatal error: Cannot use string offset as an array in %sbug39304.php on line 3 Diff: 001+ Notice: Uninitialized string offset: 0 ... Would be this a problem? Looks right to me... Finally, any objection? Tests for the this fix: - http://felipe.ath.cx/diff/bug39018.phpt - http://felipe.ath.cx/diff/bug39018_2.phpt Thanks. -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fix for #39018 (suppressing error messages)
It means You didn't commit, nobody cares. Read: Just commit..that'll wake them up. ;) --Jani On Fri, 2008-03-07 at 12:43 -0300, Felipe Pena wrote: Hello, no reply means no! don't touch. ? Thanks. 2008/3/3, Felipe Pena [EMAIL PROTECTED]: Hello developers, I made a patch for the bug#39018: $x = 'test'; @$x[4] == 'a'; (@$x[4]) == 'a'; (@($x[4])) == 'a'; @($x[4]) == 'a'; $foo = 'test'; $x = @$foo[6]; Actually, all cases above shows E_NOTICE. With the patch, E_NOTICE is not showed. Patches: [5.3] http://felipe.ath.cx/diff/bug39018.diff [HEAD] http://felipe.ath.cx/diff/bug39018-HEAD.diff However, this patch breaks one test in Zend/tests/, because of an E_NOTICE: --TEST-- Bug #39304 (Segmentation fault with list unpacking of string offset) --FILE-- ?php $s = ; list($a, $b) = $s[0]; ? --EXPECTF-- Fatal error: Cannot use string offset as an array in %sbug39304.php on line 3 Diff: 001+ Notice: Uninitialized string offset: 0 ... Would be this a problem? Looks right to me... Finally, any objection? Tests for the this fix: - http://felipe.ath.cx/diff/bug39018.phpt - http://felipe.ath.cx/diff/bug39018_2.phpt Thanks. -- Regards, Felipe Pena. -- Patches/Donations: http://pecl.php.net/~jani/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] short_open_tag
Hi! I wonder - is there a reason why short_open_tag config value is per-dir and not PHP_INI_ALL? After all, as I understand, it is private for each compilation. So suppose you preferred it generally off (you do XML, etc.) but you have some files in your app where you want it on - would there be any problem anywhere if it were INI_ALL? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fix for #39018 (suppressing error messages)
Hi! no reply means no! don't touch. ? Usually it means doesn't look bad enough to cry out right now, need time to figure it out :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Hi Stas, Am Freitag, den 07.03.2008, 12:45 -0800 schrieb Stanislav Malyshev: [...] I wonder - is there a reason why short_open_tag config value is per-dir and not PHP_INI_ALL? After all, as I understand, it is private for each compilation. So suppose you preferred it generally off (you do XML, etc.) but you have some files in your app where you want it on - would there be any problem anywhere if it were INI_ALL? This is a great idea as some framework use plain PHP scripts for templating nowadays. So the view could enable short tags for the time the template script is evaluated and disable it afterwards. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] RFC: How PHP utilizes the Google SoC
Hello Philip, first of all I filled in the application after I informed the people running the program. As soon as we get approved you will hear more from me. Until then I am happy that you do all this work and collect ideas. marcus Tuesday, March 4, 2008, 11:17:45 PM, you wrote: The Google Summer of Code sponsors students to work on Open Source projects over each summer. This RFC introduces guidelines and goals involving how we handle the SoC process. Synopsis: - Nominate an administrator early, encourage idea development year round, and focus on nominating current contributors over new ones. The Administrator: - The SoC Administrator is designated - hopefully before February 1. Administrative duties: - - organize the ideas page with summer long tasks - evaluate PHP project contributors for possible mentors and students - mind all official SoC guidelines/timelines - begin process for the following year Choosing projects: - An official goal[1] of SoC is to encourage new contributors to the Open Source world. This RFC selfishly proposes an alternative yet defined angle for accomplishing this goal. We first encourage students to become accustomed to the PHP process, peers, and learn the quirks that go on around here. And later, they may apply for an SoC project. Benefits: - efficiency - can start work today - in-house feel - better retention - a higher bus factor Downsides: - distracted by other php.net tasks - encourages less outside proposals - delays - i'll wait for the summer The benefits are good, and while kept in mind the downsides can be dealt with. Dealing with the downsides: - - students are discouraged by peers to work on other parts of the PHP project - peers are encouraged to take on the students current php.net tasks - be clear that all ideas by anyone are accepted, but in-house is preferred - maintain a How can I help PHP today? guide with HOWTO: - create and submit a patch - resolve bugs - help maintain a pecl extension - write unit tests - write documentation, and/or translate - deal with user notes - ... Ideas: - Idea generation and brain storming is encouraged all year, and ideas may be implemented at any time by any person. But once the summer nears, they (the ones not yet started) essentially become reserved as possible SoC proposals. Ideas that directly help php.net operations receive moderate preference. Eventually idea management becomes its own beast, with SoC ideas being only a small part of that task. This year: - This year we assign both new and current people, but in future years encourage people to join the PHP project first, and then potentially utilize the Google SoC later. Regards, Philip [1] http://code.google.com/soc/2008/faqs.html#0.1_goals Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] profiling followup on addition of streams to include_path - it's *faster*
Hi,
When I posted yesterday's patch to add stream support to include_path
(http://news.php.net/php.internals/36031) I mentioned that I suspected
benchmarking would reveal it to be slow. My primary goal is to provide
no impact on current users who are using a traditional include_path,
with a secondary goal of improving performance of those who use the new
syntax. Today I ran callgrind on the thing, with some surprising results.
With the patch, include is *faster* for our traditional users than it is
now.
With the patch, include_once with 1000 unique files is about 3% slower
- not the whole execution, just include_once
With the patch, include_once with 1 unique file included 1 times is
insignificantly slower (about 0.4%)
For these reasons, I'm really encouraged :). The next step is to
absolutely ensure correctness and then see if the streams part of
include_path can be optimized at all (or if it needs it).
Details
==
I just ran callgrind on this script:
?php
set_include_path('.:/usr/local/lib/php:/home/cellog/workspace/php5/ext/phar');
for ($i = 0; $i 10; $i++) {
include 'extra.php';
}
The empty file extra.php (zero byte) is in
/home/cellog/workspace/php5/ext/phar/extra.php ensuring that we
traverse include_path to find it.
To my great shock, the script runs *faster* with my patch, because it
executes significantly more instruction cycles in
php_stream_open_for_zend_ex without the patch.
Note that this does not measure the cost of *_once. *_once is a lot
harder to measure, so I created 10,000 files (yikes) via this script:
?php
for ($i = 1; $i = 1; $i++) file_put_contents('test' . $i, '');
and then ran this test script:
?php
set_include_path('.:/usr/local/lib/php:/home/cellog/workspace/php5/poop');
for ($i = 1; $i = 1; $i++) {
include_once 'test' . $i;
}
callgrind reported that php_resolve_path was about twice as slow as the
other version, resulting in a 3% degradation of include_once performance
over the current version (which is much faster than 5.2.x, incidentally).
Finally, to test the _once aspect of include_once, I ran this script:
?php
set_include_path('.:/usr/local/lib/php:/home/cellog/workspace/php5/ext/phar');
for ($i = 0; $i 10; $i++) {
include_once 'extra.php';
}
With this script, it really highlights the most common use case of
include/require_once: attempting to include the same file multiple
times. The difference in performance was insignificant, with callgrind
reporting a total execution portion of 75.12% for CVS, and 75.57% with
my patch.
So, it looks like the biggest performance hit would be for users
including more than 1000 different files, and would result in
approximately 3% slower performance *of include_once*. I'm curious how
many of our readers have a PHP setup that includes close to this many
files, because it seems rather unlikely to me that anyone would include
more than a few hundred in a single process.
The surprising news is that users who are using include would see a
performance improvement from my patch, so I recommend that portion be
committed regardless of other actions. This improvement proabbly
results from removing an include_path search in plain_wrapper.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] php_resolve_path correctness update (broken in CVS as well)
Hi,
php_resolve_path does not exit if passed a stream wrapper, but instead
tries to find it in include_path. This can cause really weird error
messages and breaks pecl/phar completely (and probably other stream
wrappers), so I added stream wrapper detection to the exit shunt in the
start of php_resolve_path.
The patch is otherwise the same as yesterday's.
Greg
Index: main/fopen_wrappers.c
===
RCS file: /repository/php-src/main/fopen_wrappers.c,v
retrieving revision 1.175.2.3.2.13.2.7
diff -u -r1.175.2.3.2.13.2.7 fopen_wrappers.c
--- main/fopen_wrappers.c 5 Mar 2008 13:34:12 -
1.175.2.3.2.13.2.7
+++ main/fopen_wrappers.c 8 Mar 2008 06:11:31 -
@@ -447,6 +447,9 @@
char resolved_path[MAXPATHLEN];
char trypath[MAXPATHLEN];
char *ptr, *end;
+ php_stream_wrapper *wrapper;
+ const char *p;
+ int n = 0;
if (!filename) {
return NULL;
@@ -462,21 +465,52 @@
return NULL;
}
}
+ /* test for stream wrappers and return */
+ for (p = filename; p - filename filename_length (isalnum((int)*p)
|| *p == '+' || *p == '-' || *p == '.'); p++) {
+ n++;
+ }
+
+ if (n filename_length - 3 (*p == ':') (!strncmp(//, p+1, 2)
|| ( filename_length 4 !memcmp(data, filename, 4 {
+ /* found stream wrapper, this is an absolute path until stream
wrappers implement realpath */
+ return estrndup(filename, filename_length);
+ }
- ptr = path;
+ ptr = (char *) path;
while (ptr *ptr) {
+ int len, is_stream_wrapper = 0, maybe_stream = 1;
+
end = strchr(ptr, DEFAULT_DIR_SEPARATOR);
+#ifndef PHP_WIN32
+ /* search for stream wrapper */
+ if (end - ptr = 1) {
+ maybe_stream = 0;
+ goto not_stream;
+ }
+ for (p = ptr, n = 0; p end (isalnum((int)*p) || *p == '+'
|| *p == '-' || *p == '.'); p++) {
+ n++;
+ }
+
+ if (n == end - ptr *p !strncmp(//, p+1, 2)) {
+ is_stream_wrapper = 1;
+ /* seek to real end of include_path portion */
+ end = strchr(end + 1, DEFAULT_DIR_SEPARATOR);
+ } else {
+ maybe_stream = 0;
+ }
+not_stream:
+#endif
if (end) {
if ((end-ptr) + 1 + filename_length + 1 = MAXPATHLEN) {
ptr = end + 1;
continue;
}
memcpy(trypath, ptr, end-ptr);
+ len = end-ptr;
trypath[end-ptr] = '/';
memcpy(trypath+(end-ptr)+1, filename,
filename_length+1);
ptr = end+1;
} else {
- int len = strlen(ptr);
+ len = strlen(ptr);
if (len + 1 + filename_length + 1 = MAXPATHLEN) {
break;
@@ -486,6 +520,35 @@
memcpy(trypath+len+1, filename, filename_length+1);
ptr = NULL;
}
+
+ if (!is_stream_wrapper maybe_stream) {
+ /* search for stream wrapper */
+ for (p = trypath; isalnum((int)*p) || *p == '+' || *p
== '-' || *p == '.'; p++) {
+ n++;
+ }
+ }
+
+ if (is_stream_wrapper || (n len - 3 (*p == ':') (n 1)
(!strncmp(//, p+1, 2) || !memcmp(data, trypath, 4 {
+ char *actual;
+
+ wrapper = php_stream_locate_url_wrapper(trypath,
actual, STREAM_OPEN_FOR_INCLUDE TSRMLS_CC);
+ if (wrapper == php_plain_files_wrapper) {
+ strncpy(trypath, actual, MAXPATHLEN);
+ } else if (!wrapper) {
+ /* if wrapper is NULL, there was a mal-formed
include_path stream wrapper, so skip this ptr */
+ continue;
+ } else {
+ if (wrapper-wops-url_stat) {
+ php_stream_statbuf ssb;
+
+ if (SUCCESS ==
wrapper-wops-url_stat(wrapper, trypath, 0, ssb, NULL TSRMLS_CC)) {
+ return estrdup(trypath);
+ }
+ }
+ continue;
+ }
+ }
+
if (tsrm_realpath(trypath, resolved_path TSRMLS_CC)) {
return estrdup(resolved_path);
Re: [PHP-DEV] profiling followup on addition of streams to include_path - it's *faster*
On 3/8/08, Gregory Beaver [EMAIL PROTECTED] wrote:
Hi,
When I posted yesterday's patch to add stream support to include_path
(http://news.php.net/php.internals/36031) I mentioned that I suspected
benchmarking would reveal it to be slow. My primary goal is to provide
no impact on current users who are using a traditional include_path,
with a secondary goal of improving performance of those who use the new
syntax. Today I ran callgrind on the thing, with some surprising results.
With the patch, include is *faster* for our traditional users than it is
now.
With the patch, include_once with 1000 unique files is about 3% slower
- not the whole execution, just include_once
With the patch, include_once with 1 unique file included 1 times is
insignificantly slower (about 0.4%)
For these reasons, I'm really encouraged :). The next step is to
absolutely ensure correctness and then see if the streams part of
include_path can be optimized at all (or if it needs it).
Details
==
I just ran callgrind on this script:
?php
set_include_path('.:/usr/local/lib/php:/home/cellog/workspace/php5/ext/phar');
for ($i = 0; $i 10; $i++) {
include 'extra.php';
}
The empty file extra.php (zero byte) is in
/home/cellog/workspace/php5/ext/phar/extra.php ensuring that we
traverse include_path to find it.
To my great shock, the script runs *faster* with my patch, because it
executes significantly more instruction cycles in
php_stream_open_for_zend_ex without the patch.
Note that this does not measure the cost of *_once. *_once is a lot
harder to measure, so I created 10,000 files (yikes) via this script:
?php
for ($i = 1; $i = 1; $i++) file_put_contents('test' . $i, '');
and then ran this test script:
?php
set_include_path('.:/usr/local/lib/php:/home/cellog/workspace/php5/poop');
for ($i = 1; $i = 1; $i++) {
include_once 'test' . $i;
}
callgrind reported that php_resolve_path was about twice as slow as the
other version, resulting in a 3% degradation of include_once performance
over the current version (which is much faster than 5.2.x, incidentally).
Finally, to test the _once aspect of include_once, I ran this script:
?php
set_include_path('.:/usr/local/lib/php:/home/cellog/workspace/php5/ext/phar');
for ($i = 0; $i 10; $i++) {
include_once 'extra.php';
}
With this script, it really highlights the most common use case of
include/require_once: attempting to include the same file multiple
times. The difference in performance was insignificant, with callgrind
reporting a total execution portion of 75.12% for CVS, and 75.57% with
my patch.
So, it looks like the biggest performance hit would be for users
including more than 1000 different files, and would result in
approximately 3% slower performance *of include_once*. I'm curious how
many of our readers have a PHP setup that includes close to this many
files, because it seems rather unlikely to me that anyone would include
more than a few hundred in a single process.
The surprising news is that users who are using include would see a
performance improvement from my patch, so I recommend that portion be
committed regardless of other actions. This improvement proabbly
results from removing an include_path search in plain_wrapper.
what about including(_once) by absolute path?
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Loading PHP Files from a PHP Extension
I'm not sure if this is the right list, because well, it isn't Internal to PHP and isn't it helping with PHP in any way. Regardless, I've been searching for many of hours and I would like an answer. (PS: There aren't very many people outside of this list who knows the answer to my question anyway.) Anyway, I remember once upon a time a PHP extension which loaded PHP files within the PHP extension MINIT or RINIT function. I had thought it was SPL which did this, but I appear to be wrong. Searching for material on the subject only brings up generic PHP Extension writing. I also believe I bought this up before on the mailing list and it was answered before. However, searching for my name doesn't bring up very many results (which may or may not be a good thing). If anyone knows of a resource to include PHP files within an extension during MINIT or RINIT, then I would love to know how it is done or even if it can be done. If anyone remembers an extension which does this already, please can you let me know? I thought that php_execute_script() might work, but from the Extending and Embedding PHP book, it is used within the context of Embedding and not Extending PHP. Jacob Santos -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
