RE: [PHP-DEV] ignored patches
I am a developer on a CMS also which uses the auto-include functionality to include many classes over many files. Each request can include up to 30 different files. The speed increase is around the 15% mark when combining the files. This is with APC installed too. I heard rumours however that php6 is not going to have such an issue with inclusion performance (something about caching of the inheritance tree in APC?). I would just like to say that if there is still a performance issue in php6, I would like to see the multiple namespaces per file functionality added. But this is the only reason. SCOTT MCNAUGHT Software Developer Synergy 8 / +617 3397 5212 [EMAIL PROTECTED] -Original Message- From: Gregory Beaver [mailto:[EMAIL PROTECTED] Sent: Monday, 3 December 2007 5:30 PM To: Stanislav Malyshev Cc: internals Mailing List Subject: Re: [PHP-DEV] ignored patches Stanislav Malyshev wrote: As for multiple namespaces per file, it adds certain complications, both syntax-wise and engine-wise, so I'm still not 100% convinced it is worth it. Which are? Remember, we both found, independently, that combining separate files yields from a 10-30% performance increase. I have only talked to 2 developers who would be using namespaces that don't want this feature. Of course, these two developers are the only people who would be using namespaces with commit access to the Zend/ tree, but that doesn't make the feature unnecessary. If you'd like, I could put you in contact with developers who have been struggling with combining files for several years now. Anecdotally, I heard of a recent file-combining optimization to a very popular CMS that resulted in a 45% performance improvement. Improving the SQL queries led to only 9% improvement, so really the only reason not to implement the multiple namespaces per-file patch is if you actually *want* a large number of php devs to be annoyed at you :) Thanks, Greg -- 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
[PHP-DEV] PHP 4 Bug Summary Report
PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (626 total including feature requests) ===[*Compile Issues]== 43389 Open configure ignoring --without-cdb flag ===[*Programming Data Structures]= 40496 Assigned Test bug35239.phpt still fails (works in PHP 5) ===[Apache2 related]== 38670 Open Whole 4.4.x branch has problem with open_basedir option nested from Apache2 ===[Arrays related]=== 31114 Assigned foreach modify array (works with PHP 5.1) 37451 Open array_multisort fails to trigger by val copy of data (works in PHP = 5.1) 39764 Suspended array_key_exists inconsistent behavior 42177 Open Warning array_merge_recursive(): recursion detected comes again... ===[CGI related]== 42180 Open php in fastcgi environment periodicaly get 90% of CPU ===[Class/Object related]= 39254 Open Refcount error with static variables and object references (PHP4 only) ===[Date/time related] 43472 Open strtotime(first Sunday ... does not work in command line ===[Documentation problem] 29045 Suspended gzopen for URL 36663 Open unexpected difference between zlib.output_compression and ob_gzhandler ===[FDF related]== 34811 Assigned fdf_get_value max size ===[Feature/Change Request]=== 3066 Open Parameter for dns functions to select different DNS 3799 Suspended default_charset brings small incompatibility 3830 Open Function to timeout/break off a function 5007 Analyzed enable no-resolve mode for here docs 5169 Open Missing recursive behavior 5311 Analyzed implement checkdnsrr() and getmxrr() on windows 5575 Open open_basedir to ~ 5601 Analyzed @function() should not turn of error reporting for critical errors 5804 Open parser error if any spaces follow indentifier in with here doc syntax 5883 Assigned --enable-trans-sid modification request 5954 Open Informix can't reliably figure if a text result column is NULL 5975 Open version of strip_tags() that specifies tags to strip (instead of tags to keep) 6118 Open Can not supress runtime warnings on foreach 6268 Open ternary op return only by value 6399 Open checkdate should be able to validate a time as well as a date (timestamp) 6427 Open func_get_arg() does not support references 6503 Open no support for multiple resultset query? 6512 Analyzed sort() Does not sort stings as expected 6574 Open SMTP functions via IMAP c-client library 6680 Open regexps (ereg*) ignores locale settings 6911 Open Problem with array_merge(_recursive) 6927 Suspended 6932 Open Filesize / File_exists and include_path 6993 Open uninstalling is a pain in the ass 7006 Open preg_replace ( string pattern, array replacement, string subject ); 7028 Analyzed xml=shared and wddx do not work together 7132 Assigned fsockopen doesn't report dns lookup failure 7398 Open Stored procedure error return values not passed through 7507 Open Better ODBC error reporting/fetching 7541 Open please consider also support HPUX shl_* 7553 Open RFC: Uplevel Block structure 7559 Open zend_hash_get_current_key_ex returning persistent strings 7578 Open next() and current() do not return referenceing arrays 7808 Open variable value triggerd by function 7923 Analyzed htmlentities doesn't work for ISO 8859-2 7930 Open List() constructor reference assignment 8100 Assigned extract(), extra feature 8108 Analyzed implement trans-sid as output handler 8295 Open absolute path in extension= directive in php.ini not recognized 8395 Open register_shutdown_function() error 8397 Open Multi-results sets are not suppported 8427 Analyzed Unwanted references 8428 Open continue doesn't pass thru a switch statement 8595 Open More effective parsing of list() (+other) 8640 Open enumeration type 8685 Open heredoc: remove column 1 closing identifier requirement 8809 Open Cookieless session with Header redirects 8827 Open PHP_AUTH_PW stores password when using External Authentication 8855 Open session_start should return also FALSE 8897 Open Significant portions of the InterBase API have no PHP representation. 8948 Open readline_completion_function enhance 9095 Open colon/semicolon delimitd extension_dir ? 9195 Analyzed Default class function arguments 9262 Analyzed Inconsistency in
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net Num Status Summary (63 total including feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers 43408 Open get_called_class not working as expected ===[*Unicode Issues]== 42163 Open fgetcsv() gives different output with and without Unicode ===[Apache2 related]== 42209 Open fail on make for sapi/apache2handler/apache_config.lo ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Assigned array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 33595 Assigned recursive references leak memory 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api ===[Feature/Change Request]=== 20377 Open php_admin_value affects _only_ .htaccess 27618 Open curl_multi_info_read does not appear to work 28261 Open Lifting reserved keyword restriction for method names 29479 Suspended changing current process name 34211 Open PDO_OCI: Allow for data type TIMESTAMP(0) WITH LOCAL TIME ZONE 34252 Open Base functions extension and refactoring 34527 Open trim functions extension 34775 Open parse_url() provide better error description on failure 34882 Open Unable to access *original* posted variable name with dot in 35309 Open Database connection pooling 37081 Open Make the include-errors mention faulty permissions 37380 Open DOMDocument-createAttribute[NS] can't set value 37546 Open DOMDocumentFragment-appendXML namespace support 37796 Open t_is_not_identical for ? 38622 Open Proposed new security scheme for shared hosting (safe mode substitute) 38946 Open pecl/docblock should be merged into ext/tokenizer 40013 Open php_uname() doesnt return nodename 40499 Open filter sapi does not register any highlightning filter 41019 Assigned auto update feature for FastCGI for IIS 41119 Open range() function behavior different on PHP6 and PHP5 41602 Open POSIX functions on Windows using Cygwin Library 42262 Open get_magic_quotes_gpc() should be there and return false 42727 Open Zend doesn't fail with syntax error 42922 Open request for 64bit numbers in php6 ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir) 42037 Open fgetc() retuns one char when fails to read on php6 42057 Open fwrite() writes data into file when length is given as a negative value 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 42125 Open fgetss reads an extra char from file created using file_put_content() 42126 Open size of the file differ, when created using file_put_content() on php6 42167 Open fgetcsv gives different output on php6 compared to php5 42219 Open length argument of fgetcsv() is not effective/working in PHP6 42229 Open fgetcsv() behaves differently for a file containing '\n' with php5 and php6. ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket 42079 Open pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated) ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON.
RE: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard extension
Hi,
I have been doing some code-reading. Why is the RSHUTDOWN function for
syslog ext called only when run under win32?
Shouldn't the cleanup happen on linux as well?
Another question is for the use of zend_strndup instead of one of the
non-persistent memory allocation functions (i.e. estrndup() ) ?
There is no use for this variable after the request dies (as far as I
understand).
However, so far, I can't seem to understand who/what corrupts my memory.
What do you think about extending the RINIT function instead of:
PHP_RINIT_FUNCTION(syslog)
{
if (INI_INT(define_syslog_variables)) {
start_syslog(TSRMLS_C);
} else {
BG(syslog_started)=0;
}
return SUCCESS;
}
To be:
PHP_RINIT_FUNCTION(syslog)
{
if (INI_INT(define_syslog_variables)) {
start_syslog(TSRMLS_C);
} else {
BG(syslog_started)=0;
BG(syslog_device)=NULL; /* This is the addition */
}
return SUCCESS;
}
Thanks in advance, Nir.
-Original Message-
From: Rachmel, Nir (Nir) [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 02, 2007 11:31 AM
To: Antony Dovgal
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard
extension
Hi,
I tried your advice, and put a breakpoint at the shutdown function.
However it never reaches it! (not normally, and not before the SEGV is
sent).
In case I didn't write it in the previous threads, I am running the PHP
scripts from my web-server (appWeb, which is apache like for embedded
systems). PHP is compiled as a static module into it, so maybe the
shutdown procedure is never called since the PHP is never shut down?
I would appreciate any advice / ideas you might have,
Thanks in advance, Nir.
-Original Message-
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 27, 2007 8:40 AM
To: Rachmel, Nir (Nir)
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard
extension
On 25.11.2007 19:55, Rachmel, Nir (Nir) wrote:
If it helps, I am attaching the relevant tsrm_ls (according to the
globals_id in the relevant frame):
syslog_started = 1,
syslog_device = 0x5a5a5a5a Address 0x5a5a5a5a out of bounds,
So it's somehow got freed.
Try setting breakpoint to zm_shutdown_syslog() function to see if it was
called before.
It should be called on shutdown only, but that's the only case when
BG(syslog_device) is freed and not NULLed.
--
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] FW: [PHP] PHP 5.2.3 segfault with syslog standard extension
On 03.12.2007 18:19, Rachmel, Nir (Nir) wrote:
Hi,
I have been doing some code-reading. Why is the RSHUTDOWN function for
syslog ext called only when run under win32?
Shouldn't the cleanup happen on linux as well?
`man closelog` says it's not required.
DESCRIPTION
closelog() closes the descriptor being used to write to the system
logger. The use of closelog() is optional.
Another question is for the use of zend_strndup instead of one of the
non-persistent memory allocation functions (i.e. estrndup() ) ?
There is no use for this variable after the request dies (as far as I
understand).
Right, if you use estrndup(), the memory is freed at the end of request,
while zend_strndup() bypasses Zend memory manager using malloc() directly.
However, so far, I can't seem to understand who/what corrupts my memory.
Me neither :/
What do you think about extending the RINIT function instead of:
PHP_RINIT_FUNCTION(syslog)
{
if (INI_INT(define_syslog_variables)) {
start_syslog(TSRMLS_C);
} else {
BG(syslog_started)=0;
BG(syslog_device)=NULL; /* This is the addition */
I think this would just create a memleak.
BG(syslog_device) is checked for NULL and freed in openlog() and MSHUTDOWN.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Object Oriented standard Library
I am currently working on a Object-Oriented Library extension that wraps a lot of functionality in PHP's standard library dealing with strings, arrays, fileIO, etc. into classes. (String class, Collection class, etc.) This would allow end-users to create objects that represent data types and resources, and take advantage of all the benefits of OOP (object chaining, polymorphism, etc) all in a c compiled extension. Example: $myString=new String(Hello world!); $myLowerCaseString = $myString-copy()-replace(world,universe)-lowerCase(); The goal of this project is to help PHP mature into a more object-oriented language with an object oriented library, while addressing a common complaint about the standard library not being very consistent (http://en.wikipedia.org/wiki/Php#Criticism [8th bullet]) I have already implemented a couple classes, but would like to get feedback from the PHP development community on the idea of creating such a library for PHP. Also, any suggestions would be greatly appreciated. Thanks, Jordan Wambaugh
Re: [PHP-DEV] Proposed feature for json_encode()
Alexey Zakhlestin wrote: On 12/2/07, Rasmus Lerdorf [EMAIL PROTECTED] wrote: The \u syntax is specific to JSON, yes. \u syntax is specific to javascripts string literals, regular expressions and identifiers[1] And JSON is not the only way to deliver data into javascript. Manual approaches are still useful Since JSON and Javascript are synonymous, sure, \u is for javascript string literals. I thought you meant whether it was useful outside of Javascript. And I disagree with your second statement. Why wouldn't you use json anytime you wanted to jump from PHP to Javascript? script var a = ?php echo json_encode($a)?; /script That ensures that no matter what $a is on the PHP side, it will be correctly assigned to the corresponding Javascript variable. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Oriented standard Library
Hello Jordan, have a look at the SPL extension (Standard PHP Library) which introduces a few things (for instance SplFile). Have a look here: http://php.net/~helly I do not think we need a string class right now unless you want to provide a full unicode one that later works with HEAD seamingly. If you are intersted, then the ArrayObject/ArrayIterator implementation in SPL can be made much faster. I know what to do but have no time for that... and as always, help is always welcome here and if you have something to show, then show us :-) marcus Monday, December 3, 2007, 5:43:19 PM, you wrote: I am currently working on a Object-Oriented Library extension that wraps a lot of functionality in PHP's standard library dealing with strings, arrays, fileIO, etc. into classes. (String class, Collection class, etc.) This would allow end-users to create objects that represent data types and resources, and take advantage of all the benefits of OOP (object chaining, polymorphism, etc) all in a c compiled extension. Example: $myString=new String(Hello world!); $myLowerCaseString = $myString-copy()-replace(world,universe)-lowerCase(); The goal of this project is to help PHP mature into a more object-oriented language with an object oriented library, while addressing a common complaint about the standard library not being very consistent (http://en.wikipedia.org/wiki/Php#Criticism [8th bullet]) I have already implemented a couple classes, but would like to get feedback from the PHP development community on the idea of creating such a library for PHP. Also, any suggestions would be greatly appreciated. Thanks, Jordan Wambaugh Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] people.php.net
You mean something like http://pear.php.net/map ? On Dec 3, 2007 12:44 PM, Rasmus Lerdorf [EMAIL PROTECTED] wrote: I have some new code for it. I'll try to find some time to update it over the next couple of weeks. -Rasmus Silvano Girardi Jr wrote: Gentleman, This morning I went to see Lukas speaking at the Brazilian PHP Conference and he mentioned http://people.php.net He said that it started with the idea to map the PEAR developers. I went to see it but the project seems to be stuck. Also, I was trying to find out on the mailings what you guys have already discussed about it but I have found nothing. Google shows only Antony asking on his blog if the idea died even before it was born :P I am starting a project here that could fit on the people.php.net so I'd like to know who is currently responsible for that and what I can do to help or perhaps assume it so we can have it moving forward. For those that saw the [EMAIL PROTECTED] and is wondering who I am, I have my account since 2005 when I put in the PEAR Validate_ptBR package but did not make more contributions since then. I'd like to get back with contributions and make my account worth. Regards, Silvano Girardi Jr. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] people.php.net
I have some new code for it. I'll try to find some time to update it over the next couple of weeks. -Rasmus Silvano Girardi Jr wrote: Gentleman, This morning I went to see Lukas speaking at the Brazilian PHP Conference and he mentioned http://people.php.net He said that it started with the idea to map the PEAR developers. I went to see it but the project seems to be stuck. Also, I was trying to find out on the mailings what you guys have already discussed about it but I have found nothing. Google shows only Antony asking on his blog if the idea died even before it was born :P I am starting a project here that could fit on the people.php.net so I'd like to know who is currently responsible for that and what I can do to help or perhaps assume it so we can have it moving forward. For those that saw the [EMAIL PROTECTED] and is wondering who I am, I have my account since 2005 when I put in the PEAR Validate_ptBR package but did not make more contributions since then. I'd like to get back with contributions and make my account worth. Regards, Silvano Girardi Jr. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] people.php.net
Nah, it does more than that. David Coallier wrote: You mean something like http://pear.php.net/map ? On Dec 3, 2007 12:44 PM, Rasmus Lerdorf [EMAIL PROTECTED] wrote: I have some new code for it. I'll try to find some time to update it over the next couple of weeks. -Rasmus Silvano Girardi Jr wrote: Gentleman, This morning I went to see Lukas speaking at the Brazilian PHP Conference and he mentioned http://people.php.net He said that it started with the idea to map the PEAR developers. I went to see it but the project seems to be stuck. Also, I was trying to find out on the mailings what you guys have already discussed about it but I have found nothing. Google shows only Antony asking on his blog if the idea died even before it was born :P I am starting a project here that could fit on the people.php.net so I'd like to know who is currently responsible for that and what I can do to help or perhaps assume it so we can have it moving forward. For those that saw the [EMAIL PROTECTED] and is wondering who I am, I have my account since 2005 when I put in the PEAR Validate_ptBR package but did not make more contributions since then. I'd like to get back with contributions and make my account worth. Regards, Silvano Girardi Jr. -- 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] people.php.net
Hey Rasmus, You looking for help to build that out? That project looks like TONS-OF-FUN (r), and I'd be interested in helping out with it. I think it would be great to see people on there and all the projects they are associated with, kinda like a socialcoder project ;) -ralph Rasmus Lerdorf wrote: Nah, it does more than that. David Coallier wrote: You mean something like http://pear.php.net/map ? On Dec 3, 2007 12:44 PM, Rasmus Lerdorf [EMAIL PROTECTED] wrote: I have some new code for it. I'll try to find some time to update it over the next couple of weeks. -Rasmus Silvano Girardi Jr wrote: Gentleman, This morning I went to see Lukas speaking at the Brazilian PHP Conference and he mentioned http://people.php.net He said that it started with the idea to map the PEAR developers. I went to see it but the project seems to be stuck. Also, I was trying to find out on the mailings what you guys have already discussed about it but I have found nothing. Google shows only Antony asking on his blog if the idea died even before it was born :P I am starting a project here that could fit on the people.php.net so I'd like to know who is currently responsible for that and what I can do to help or perhaps assume it so we can have it moving forward. For those that saw the [EMAIL PROTECTED] and is wondering who I am, I have my account since 2005 when I put in the PEAR Validate_ptBR package but did not make more contributions since then. I'd like to get back with contributions and make my account worth. Regards, Silvano Girardi Jr. -- 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] Object Oriented standard Library
Thanks. I was not aware of SPL's file and array classes. As for the string class, some of it is done, and should work in 5.x HEAD. I fully plan to add Unicode support for PHP 6's HEAD. Is there any other concerns you may have about a string class (other than it being a big task)? I think it would be great to unify, and standardize all the string functions in PHP into a class. I don't want to rewrite anything already written, so I'll go ahead and take a look at ArrayObject and ArrayIterator. I'd love to help PHP as much as possible. Thanks, Jordan. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 12:18 PM To: Jordan Wambaugh Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Object Oriented standard Library Hello Jordan, have a look at the SPL extension (Standard PHP Library) which introduces a few things (for instance SplFile). Have a look here: http://php.net/~helly I do not think we need a string class right now unless you want to provide a full unicode one that later works with HEAD seamingly. If you are intersted, then the ArrayObject/ArrayIterator implementation in SPL can be made much faster. I know what to do but have no time for that... and as always, help is always welcome here and if you have something to show, then show us :-) marcus Monday, December 3, 2007, 5:43:19 PM, you wrote: I am currently working on a Object-Oriented Library extension that wraps a lot of functionality in PHP's standard library dealing with strings, arrays, fileIO, etc. into classes. (String class, Collection class, etc.) This would allow end-users to create objects that represent data types and resources, and take advantage of all the benefits of OOP (object chaining, polymorphism, etc) all in a c compiled extension. Example: $myString=new String(Hello world!); $myLowerCaseString = $myString-copy()-replace(world,universe)-lowerCase(); The goal of this project is to help PHP mature into a more object-oriented language with an object oriented library, while addressing a common complaint about the standard library not being very consistent (http://en.wikipedia.org/wiki/Php#Criticism [8th bullet]) I have already implemented a couple classes, but would like to get feedback from the PHP development community on the idea of creating such a library for PHP. Also, any suggestions would be greatly appreciated. Thanks, Jordan Wambaugh Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Garbage collector patch
Hi all, Was hoping to send this off earlier but I was travelling for the past week and had very limited email access. As promised in the past few weeks we have spent a significant amount of time in reviewing the garbage collector work and testing it in our performance lab. Dmitry has been exchanging ideas and patches with David Wang during this time. Suffice to say that as I've mentioned in the past, memory management is an extremely sensitive piece of PHP, which is why it was important for us to review this work in great depth before committing it to the code base. The updated patch still retains the same algorithm as David's original implementation however the data structures have been changed in order to work faster and use less memory. The revised patch has the following advantages: - It fixes several crash bugs - Enhances performance by removing several unnecessary checks - The memory overhead was reduced (from 12 to 4 bytes for each heap-allocated zval) - The speed of clean PHP code (code that doesn't create cycles) was improved - Additional test cases were created The end result is a more stable and faster GC patch. That said we have yet to find real-life applications that create significant cycles which would benefit from this patch. In fact as you'll see from the results our tests show an increase in maximum memory use and slower execution (to be fair they are marginal). We have tested both PHP_5_3 without any patches, the original patch and the new patch. The following table shows execution time (seconds for N requests) and slowdown. PHP_5_3 Original GC patch Current GC patch slowdown slowdown bench 11,550 12,310 6,58% 12,170 5,37% hello 8,781 8,852 0,81% 8,813 0,36% xoops 128,500 135,100 5,14% 130,200 1,32% static 18,540 20,840 12,41% 18,920 2,05% qdig 29,320 30,270 3,24% 29,610 0,99% qdig2 13,960 14,100 1,00% 14,090 0,93% The next table shows memory usage in MB and overhead PHP_5_3 Original GC patch Current GC patch overhead overhead hello 13,750 13,945 1,42% 13,765 0,11% xoops 18,036 18,636 3,33% 18,568 2,95% static 15,300 16,000 4,58% 15,308 0,05% qdig 14,820 15,008 1,27% 14,828 0,05% qdig2 14,824 15,012 1,27% 14,838 0,09% To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). We also tested SugarCRM to get another sanity for these results and we got similar results. I am not quite sure where this leaves us with this patch. On one hand I think now the effort has been made it's a good thing to offer it as part of PHP. The downside is of course some performance degradation and possible instabilities as this patch continues to stabilize (it took about two releases for us to stabilize the Zend Memory Manager even after in-depth testing due to edge cases in allocation patterns and various extensions, etc...).I'd be surprised if our team has found all possible bugs. Personally I think the decision should be either in or out. Adding this as a compile option is not a good idea as it would create binary compatibility issues and would be a pain for the community. I think my inclination is to commit the patch, not have it #ifdef'ed but always compiled but to have the garbage collection itself turned off by default (mainly for stability reasons. Note: the increased memory footprint and performance loss also exists with the collection itself turned off). We can turn it on when we're in dev for snapshots so that we iron out bugs. That said, as you can see from the results most people and real-life applications will be worse off than today. Thanks to David Dmitry for working hard on this (and everyone else who contributed). The stage is open for ideas/thoughts/suggestions J Andi
Re: [PHP-DEV] Garbage collector patch
On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Hi all, Was hoping to send this off earlier but I was travelling for the past week and had very limited email access. As promised in the past few weeks we have spent a significant amount of time in reviewing the garbage collector work and testing it in our performance lab. Dmitry has been exchanging ideas and patches with David Wang during this time. Suffice to say that as I've mentioned in the past, memory management is an extremely sensitive piece of PHP, which is why it was important for us to review this work in great depth before committing it to the code base. The updated patch still retains the same algorithm as David's original implementation however the data structures have been changed in order to work faster and use less memory. The revised patch has the following advantages: - It fixes several crash bugs - Enhances performance by removing several unnecessary checks - The memory overhead was reduced (from 12 to 4 bytes for each heap-allocated zval) - The speed of clean PHP code (code that doesn't create cycles) was improved - Additional test cases were created The end result is a more stable and faster GC patch. That said we have yet to find real-life applications that create significant cycles which would benefit from this patch. In fact as you'll see from the results our tests show an increase in maximum memory use and slower execution (to be fair they are marginal). We have tested both PHP_5_3 without any patches, the original patch and the new patch. The following table shows execution time (seconds for N requests) and slowdown. PHP_5_3 Original GC patch Current GC patch slowdown slowdown bench 11,550 12,310 6,58% 12,170 5,37% hello 8,781 8,852 0,81% 8,813 0,36% xoops 128,500 135,100 5,14% 130,200 1,32% static 18,540 20,840 12,41% 18,920 2,05% qdig 29,320 30,270 3,24% 29,610 0,99% qdig2 13,960 14,100 1,00% 14,090 0,93% The next table shows memory usage in MB and overhead PHP_5_3 Original GC patch Current GC patch overhead overhead hello 13,750 13,945 1,42% 13,765 0,11% xoops 18,036 18,636 3,33% 18,568 2,95% static 15,300 16,000 4,58% 15,308 0,05% qdig 14,820 15,008 1,27% 14,828 0,05% qdig2 14,824 15,012 1,27% 14,838 0,09% To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). We also tested SugarCRM to get another sanity for these results and we got similar results. I am not quite sure where this leaves us with this patch. On one hand I think now the effort has been made it's a good thing to offer it as part of PHP. The downside is of course some performance degradation and possible instabilities as this patch continues to stabilize (it took about two releases for us to stabilize the Zend Memory Manager even after in-depth testing due to edge cases in allocation patterns and various extensions, etc...).I'd be surprised if our team has found all possible bugs. Personally I think the decision should be either in or out. Adding this as a compile option is not a good idea as it would create binary compatibility issues and would be a pain for the community. I think my inclination is to commit the patch, not have it #ifdef'ed but always compiled but to have the garbage collection itself turned off by default (mainly for stability reasons. Note: the increased memory footprint and performance loss also exists with the collection itself turned off). We can turn it on when we're in dev for snapshots so that we iron out bugs. That said, as you can see from the results most people and real-life applications will be worse off than today. Thanks to David Dmitry for working hard on this (and everyone else who contributed). The stage is open for ideas/thoughts/suggestions J Andi Andi, I don't know about how it worked for anyone else, but the tables didn't display properly on Gmail, so I had a hard time keeping up with the performance differences. If you have this in a separate file, could you send it to me as an attachment? I have a few real-world benchmarks I'd like to try from the angle of the shared-webhost industry (lots of users with horrible code running simultaneously, et cetera) which I'd like to compare to your notes. Thanks. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
Re: [PHP-DEV] Garbage collector patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Daniel Brown wrote: I don't know about how it worked for anyone else, but the tables didn't display properly on Gmail, so I had a hard time keeping up with the performance differences. If you have this in a separate file, could you send it to me as an attachment? Same problem, all in one row, to table to read. We're having non-apache application which run up to one hour to do their task and I think our QA can test the new GC there (and memory consumption is an issue there definitely). thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHVHWh1nS0RcInK9ARAmPlAJ9XnOzFmLSl8qDxY5bLBfJBcmgqRACfZnsn R3cFSHfkMpoffq+f5vMxI3g= =OkMW -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
That'd be great. Dmitry, David, can you please send the updated patch to the list? Andi -Original Message- From: Markus Fischer [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 1:31 PM To: Daniel Brown Cc: Andi Gutmans; internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Daniel Brown wrote: I don't know about how it worked for anyone else, but the tables didn't display properly on Gmail, so I had a hard time keeping up with the performance differences. If you have this in a separate file, could you send it to me as an attachment? Same problem, all in one row, to table to read. We're having non-apache application which run up to one hour to do their task and I think our QA can test the new GC there (and memory consumption is an issue there definitely). thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHVHWh1nS0RcInK9ARAmPlAJ9XnOzFmLSl8qDxY5bLBfJBcmgqRACfZnsn R3cFSHfkMpoffq+f5vMxI3g= =OkMW -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
That looks great, Andi. Thanks. On Dec 3, 2007 4:38 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Sorry about that. Does the attached PDFed screenshot work for you? Andi -Original Message- From: Daniel Brown [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 1:21 PM To: Andi Gutmans Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Hi all, Was hoping to send this off earlier but I was travelling for the past week and had very limited email access. As promised in the past few weeks we have spent a significant amount of time in reviewing the garbage collector work and testing it in our performance lab. Dmitry has been exchanging ideas and patches with David Wang during this time. Suffice to say that as I've mentioned in the past, memory management is an extremely sensitive piece of PHP, which is why it was important for us to review this work in great depth before committing it to the code base. The updated patch still retains the same algorithm as David's original implementation however the data structures have been changed in order to work faster and use less memory. The revised patch has the following advantages: - It fixes several crash bugs - Enhances performance by removing several unnecessary checks - The memory overhead was reduced (from 12 to 4 bytes for each heap-allocated zval) - The speed of clean PHP code (code that doesn't create cycles) was improved - Additional test cases were created The end result is a more stable and faster GC patch. That said we have yet to find real-life applications that create significant cycles which would benefit from this patch. In fact as you'll see from the results our tests show an increase in maximum memory use and slower execution (to be fair they are marginal). We have tested both PHP_5_3 without any patches, the original patch and the new patch. The following table shows execution time (seconds for N requests) and slowdown. PHP_5_3 Original GC patch Current GC patch slowdown slowdown bench 11,550 12,310 6,58% 12,170 5,37% hello 8,781 8,852 0,81% 8,813 0,36% xoops 128,500 135,100 5,14% 130,200 1,32% static 18,540 20,840 12,41% 18,920 2,05% qdig 29,320 30,270 3,24% 29,610 0,99% qdig2 13,960 14,100 1,00% 14,090 0,93% The next table shows memory usage in MB and overhead PHP_5_3 Original GC patch Current GC patch overhead overhead hello 13,750 13,945 1,42% 13,765 0,11% xoops 18,036 18,636 3,33% 18,568 2,95% static 15,300 16,000 4,58% 15,308 0,05% qdig 14,820 15,008 1,27% 14,828 0,05% qdig2 14,824 15,012 1,27% 14,838 0,09% To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). We also tested SugarCRM to get another sanity for these results and we got similar results. I am not quite sure where this leaves us with this patch. On one hand I think now the effort has been made it's a good thing to offer it as part of PHP. The downside is of course some performance degradation and possible instabilities as this patch continues to stabilize (it took about two releases for us to stabilize the Zend Memory Manager even after in-depth testing due to edge cases in allocation patterns and various extensions, etc...).I'd be surprised if our team has found all possible bugs. Personally I think the decision should be either in or out. Adding this as a compile option is not a good idea as it would create binary compatibility issues and would be a pain for the community. I think my inclination is to commit the patch, not have it #ifdef'ed but always compiled but to have the garbage collection itself turned off by default (mainly for stability reasons. Note: the increased memory footprint and performance loss also exists with the collection itself turned off). We can turn it on when we're in dev for snapshots so that we iron out bugs. That said, as you can see from the results most people and real-life applications will be worse off than today.
Re: [PHP-DEV] Garbage collector patch
Markus, If for some reason the PDF attachment didn't come through to you on the list, let me know and I'll upload it to one of my servers for you to download and use, as well. On Dec 3, 2007 4:40 PM, Daniel Brown [EMAIL PROTECTED] wrote: That looks great, Andi. Thanks. On Dec 3, 2007 4:38 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Sorry about that. Does the attached PDFed screenshot work for you? Andi -Original Message- From: Daniel Brown [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 1:21 PM To: Andi Gutmans Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Hi all, Was hoping to send this off earlier but I was travelling for the past week and had very limited email access. As promised in the past few weeks we have spent a significant amount of time in reviewing the garbage collector work and testing it in our performance lab. Dmitry has been exchanging ideas and patches with David Wang during this time. Suffice to say that as I've mentioned in the past, memory management is an extremely sensitive piece of PHP, which is why it was important for us to review this work in great depth before committing it to the code base. The updated patch still retains the same algorithm as David's original implementation however the data structures have been changed in order to work faster and use less memory. The revised patch has the following advantages: - It fixes several crash bugs - Enhances performance by removing several unnecessary checks - The memory overhead was reduced (from 12 to 4 bytes for each heap-allocated zval) - The speed of clean PHP code (code that doesn't create cycles) was improved - Additional test cases were created The end result is a more stable and faster GC patch. That said we have yet to find real-life applications that create significant cycles which would benefit from this patch. In fact as you'll see from the results our tests show an increase in maximum memory use and slower execution (to be fair they are marginal). We have tested both PHP_5_3 without any patches, the original patch and the new patch. The following table shows execution time (seconds for N requests) and slowdown. PHP_5_3 Original GC patch Current GC patch slowdown slowdown bench 11,550 12,310 6,58% 12,170 5,37% hello 8,781 8,852 0,81% 8,813 0,36% xoops 128,500 135,100 5,14% 130,200 1,32% static 18,540 20,840 12,41% 18,920 2,05% qdig 29,320 30,270 3,24% 29,610 0,99% qdig2 13,960 14,100 1,00% 14,090 0,93% The next table shows memory usage in MB and overhead PHP_5_3 Original GC patch Current GC patch overhead overhead hello 13,750 13,945 1,42% 13,765 0,11% xoops 18,036 18,636 3,33% 18,568 2,95% static 15,300 16,000 4,58% 15,308 0,05% qdig 14,820 15,008 1,27% 14,828 0,05% qdig2 14,824 15,012 1,27% 14,838 0,09% To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). We also tested SugarCRM to get another sanity for these results and we got similar results. I am not quite sure where this leaves us with this patch. On one hand I think now the effort has been made it's a good thing to offer it as part of PHP. The downside is of course some performance degradation and possible instabilities as this patch continues to stabilize (it took about two releases for us to stabilize the Zend Memory Manager even after in-depth testing due to edge cases in allocation patterns and various extensions, etc...).I'd be surprised if our team has found all possible bugs. Personally I think the decision should be either in or out. Adding this as a compile option is not a good idea as it would create binary compatibility issues and would be a pain
Re: [PHP-DEV] Garbage collector patch
Daniel Brown wrote: If for some reason the PDF attachment didn't come through to you on the list, let me know and I'll upload it to one of my servers for you to download and use, as well. The PDF didn't make it through for me. Can you upload it? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, yes exactly, there was no PDF attachment. Interestingly the signature was a separate attachment ... thanks - - Markus Daniel Brown wrote: Markus, If for some reason the PDF attachment didn't come through to you on the list, let me know and I'll upload it to one of my servers for you to download and use, as well. On Dec 3, 2007 4:40 PM, Daniel Brown [EMAIL PROTECTED] wrote: That looks great, Andi. Thanks. On Dec 3, 2007 4:38 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Sorry about that. Does the attached PDFed screenshot work for you? Andi -Original Message- From: Daniel Brown [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 1:21 PM To: Andi Gutmans Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Hi all, Was hoping to send this off earlier but I was travelling for the past week and had very limited email access. As promised in the past few weeks we have spent a significant amount of time in reviewing the garbage collector work and testing it in our performance lab. Dmitry has been exchanging ideas and patches with David Wang during this time. Suffice to say that as I've mentioned in the past, memory management is an extremely sensitive piece of PHP, which is why it was important for us to review this work in great depth before committing it to the code base. The updated patch still retains the same algorithm as David's original implementation however the data structures have been changed in order to work faster and use less memory. The revised patch has the following advantages: - It fixes several crash bugs - Enhances performance by removing several unnecessary checks - The memory overhead was reduced (from 12 to 4 bytes for each heap-allocated zval) - The speed of clean PHP code (code that doesn't create cycles) was improved - Additional test cases were created The end result is a more stable and faster GC patch. That said we have yet to find real-life applications that create significant cycles which would benefit from this patch. In fact as you'll see from the results our tests show an increase in maximum memory use and slower execution (to be fair they are marginal). We have tested both PHP_5_3 without any patches, the original patch and the new patch. The following table shows execution time (seconds for N requests) and slowdown. PHP_5_3 Original GC patch Current GC patch slowdown slowdown bench 11,550 12,310 6,58% 12,170 5,37% hello 8,781 8,852 0,81% 8,813 0,36% xoops 128,500 135,100 5,14% 130,200 1,32% static 18,540 20,840 12,41% 18,920 2,05% qdig 29,320 30,270 3,24% 29,610 0,99% qdig2 13,960 14,100 1,00% 14,090 0,93% The next table shows memory usage in MB and overhead PHP_5_3 Original GC patch Current GC patch overhead overhead hello 13,750 13,945 1,42% 13,765 0,11% xoops 18,036 18,636 3,33% 18,568 2,95% static 15,300 16,000 4,58% 15,308 0,05% qdig 14,820 15,008 1,27% 14,828 0,05% qdig2 14,824 15,012 1,27% 14,838 0,09% To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). We also tested SugarCRM to get another sanity for these results and we got similar results. I am not quite sure where this leaves us with this patch. On one hand I think now the effort has been made it's a good thing to offer it as part of PHP. The downside is of course some performance degradation and possible instabilities as this patch continues to stabilize (it took about two releases for us to stabilize the Zend Memory Manager even after in-depth testing due to edge cases in allocation patterns and various extensions, etc...).I'd be surprised if our team has found all possible bugs. Personally I think the decision should be either in or out. Adding this as a compile option is not a good idea as it would create binary compatibility issues and would be a pain for the community. I think my inclination is to commit the patch, not have it #ifdef'ed but always compiled but to have the garbage collection itself turned off by default (mainly for stability reasons. Note: the increased memory footprint and performance loss also exists with the collection itself turned off). We can turn it on when we're in dev for snapshots so that we iron out bugs. That said, as you can see from the results most people and real-life applications will be worse off than today. Thanks to David Dmitry for working hard on this (and everyone else who
RE: [PHP-DEV] Garbage collector patch
Argh. Here you go: http://cvs.php.net/~andi/GC_email.pdf -Original Message- From: Edward Z. Yang [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 1:43 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch Daniel Brown wrote: If for some reason the PDF attachment didn't come through to you on the list, let me know and I'll upload it to one of my servers for you to download and use, as well. The PDF didn't make it through for me. Can you upload it? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
Sorry about that. Does the attached PDFed screenshot work for you? If only we knew how to publish documents on that 'web thing. (-: S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
On Mon, 3 Dec 2007, Andi Gutmans wrote: Sorry about that. Does the attached PDFed screenshot work for you? No, as you can't attach files here Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Dec 3, 2007 4:49 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 3 Dec 2007, Andi Gutmans wrote: Sorry about that. Does the attached PDFed screenshot work for you? No, as you can't attach files here Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org I didn't think it would work on the list, but I figured if Andi either sent it to me, or clicked Reply-All, either way it would be delivered directly to my inbox, which it was. So now it's here: http://www.pilotpig.net/pdfs/ -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
Sorry about that. Does the attached PDFed screenshot work for you? Andi -Original Message- From: Daniel Brown [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 1:21 PM To: Andi Gutmans Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch On Dec 3, 2007 4:01 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Hi all, Was hoping to send this off earlier but I was travelling for the past week and had very limited email access. As promised in the past few weeks we have spent a significant amount of time in reviewing the garbage collector work and testing it in our performance lab. Dmitry has been exchanging ideas and patches with David Wang during this time. Suffice to say that as I've mentioned in the past, memory management is an extremely sensitive piece of PHP, which is why it was important for us to review this work in great depth before committing it to the code base. The updated patch still retains the same algorithm as David's original implementation however the data structures have been changed in order to work faster and use less memory. The revised patch has the following advantages: - It fixes several crash bugs - Enhances performance by removing several unnecessary checks - The memory overhead was reduced (from 12 to 4 bytes for each heap-allocated zval) - The speed of clean PHP code (code that doesn't create cycles) was improved - Additional test cases were created The end result is a more stable and faster GC patch. That said we have yet to find real-life applications that create significant cycles which would benefit from this patch. In fact as you'll see from the results our tests show an increase in maximum memory use and slower execution (to be fair they are marginal). We have tested both PHP_5_3 without any patches, the original patch and the new patch. The following table shows execution time (seconds for N requests) and slowdown. PHP_5_3 Original GC patch Current GC patch slowdown slowdown bench 11,550 12,310 6,58% 12,170 5,37% hello 8,781 8,852 0,81% 8,813 0,36% xoops 128,500 135,100 5,14% 130,200 1,32% static 18,540 20,840 12,41% 18,920 2,05% qdig 29,320 30,270 3,24% 29,610 0,99% qdig2 13,960 14,100 1,00% 14,090 0,93% The next table shows memory usage in MB and overhead PHP_5_3 Original GC patch Current GC patch overhead overhead hello 13,750 13,945 1,42% 13,765 0,11% xoops 18,036 18,636 3,33% 18,568 2,95% static 15,300 16,000 4,58% 15,308 0,05% qdig 14,820 15,008 1,27% 14,828 0,05% qdig2 14,824 15,012 1,27% 14,838 0,09% To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). We also tested SugarCRM to get another sanity for these results and we got similar results. I am not quite sure where this leaves us with this patch. On one hand I think now the effort has been made it's a good thing to offer it as part of PHP. The downside is of course some performance degradation and possible instabilities as this patch continues to stabilize (it took about two releases for us to stabilize the Zend Memory Manager even after in-depth testing due to edge cases in allocation patterns and various extensions, etc...).I'd be surprised if our team has found all possible bugs. Personally I think the decision should be either in or out. Adding this as a compile option is not a good idea as it would create binary compatibility issues and would be a pain for the community. I think my inclination is to commit the patch, not have it #ifdef'ed but always compiled but to have the garbage collection itself turned off by default (mainly for stability reasons. Note: the increased memory footprint and performance loss also exists with the collection itself turned off). We can turn it on when we're in dev for snapshots so that we iron out bugs. That said, as you can see from the results most people and real-life applications will be worse off than today. Thanks to David Dmitry for working hard on this (and everyone else who contributed). The stage is open for ideas/thoughts/suggestions J Andi Andi, I don't know about how it worked for anyone else, but the tables didn't display properly on Gmail, so I had a hard time keeping up with the performance differences. If you have this in a separate
Re: [PHP-DEV] Proposed feature for json_encode()
Stuff like this often isn't completely deterministic. The attack vectors will move around and new ones will be discovered but since the syntax Sara is proposing is completely valid JSON it gives people another tool. Documenting specific attack vectors is useful too, of course, but a secondary concern in my mind. I'm not talking about attack vectors and full security analysis. For me, it is a primary concern having some security oriented feature to know *what exactly* it does and when you should and should not use it. We were burned repeatedly by implementing various cool features that were misused for doing things that they weren't meant to do and then we were blamed for it - so I think we need to have clear understanding of when and why this feature is useful and explicitly document it. Otherwise what would happen is that people would use this option, pass JS data through it, stick it into DOM, get XSS and start blogging about huge XSS in supposedly secure json_encode() function in PHP. Or, not seeing how it can help them, won't use it at 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] ignored patches
I am a developer on a CMS also which uses the auto-include functionality to include many classes over many files. Each request can include up to 30 different files. The speed increase is around the 15% mark when combining the files. This is with APC installed too. Can you provide some benchmark setups that this could be researched - i.e. describe what was benchmarked and how to reproduce it? -- 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] ignored patches
Remember, we both found, independently, that combining separate files yields from a 10-30% performance increase. I have only talked to 2 On synthetic benchmarks. On real apps, which do databases, calculations, network, etc. that would be probably no more than 5%, probably even less. And I don't see any application shipping in this format. This is a very problematic issue - adding a feature into a language that serves only very specific very narrow performance scenario but which will inevitably be widely abused in cases which have nothing to do with that scenario. the feature unnecessary. If you'd like, I could put you in contact with developers who have been struggling with combining files for several years now. Why were they struggling - only problem existing with it is namespaces, and they certainly couldn't try to use namespaces for years? If they had other problems, they will keep having them and multiple namespaces per file are not going to help them. Anecdotally, I heard of a recent file-combining optimization to a very popular CMS that resulted in a 45% performance improvement. Improving Did they use bytecode caching? Anyway, I have hard time believing PHP include is so broken, but if it is - it should be fixed, not through creating syntax-level workarounds but directly. really the only reason not to implement the multiple namespaces per-file I think I described my reasons now multiple times. -- 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
[PHP-DEV] Bug #38915
May we get a reply to Bug #38915? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
Stanislav Malyshev wrote: Stuff like this often isn't completely deterministic. The attack vectors will move around and new ones will be discovered but since the syntax Sara is proposing is completely valid JSON it gives people another tool. Documenting specific attack vectors is useful too, of course, but a secondary concern in my mind. I'm not talking about attack vectors and full security analysis. For me, it is a primary concern having some security oriented feature to know *what exactly* it does and when you should and should not use it. We were burned repeatedly by implementing various cool features that were misused for doing things that they weren't meant to do and then we were blamed for it - so I think we need to have clear understanding of when and why this feature is useful and explicitly document it. Otherwise what would happen is that people would use this option, pass JS data through it, stick it into DOM, get XSS and start blogging about huge XSS in supposedly secure json_encode() function in PHP. Or, not seeing how it can help them, won't use it at all. This is just a different way of encoding Javascript which depending on the context of use will enable Javascript to be embedded securely. Not providing an alternate encoding is a bit like arguing that we shouldn't have base64_encode() because if used incorrectly it could be insecure. We don't have an explanation of when base64_encode() is useful in the docs, although I suppose we could come up with some scenarios for when you want to squeeze arbitrary data into the set of characters base64_encode() uses. Same thing for this json_encode() feature. We can come up with a set of scenarios where we would like to avoid having characters that are meaningful in XML and HTML show up in our json strings. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
This is just a different way of encoding Javascript which depending on the context of use will enable Javascript to be embedded securely. Not providing an alternate encoding is a bit like arguing that we shouldn't have base64_encode() because if used incorrectly it could be insecure. I'm not saying not providing, I'm saying we should provide use cases, otherwise this feature will inevitably be misused. We don't have an explanation of when base64_encode() is useful in the Because it's established standard that is widely used. json_encode() option was never used before. base64_encode() uses. Same thing for this json_encode() feature. We can come up with a set of scenarios where we would like to avoid having characters that are meaningful in XML and HTML show up in our json strings. OK, we can. Let's do. -- 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] ignored patches
Hi Stats, Everybody is providing clear and proven results. You are the only one who is throwing around hypothetical numbers (that 5% figure comes out of your head). Can you please be more responsible and provide some real results ? Also, pretty much every feature of a language can be abused. From my point of view, using autoload for every class IS abusive (as we all know, thanks to many benchmarks, that it affects performance negatively). But I don't defend its abolition because of that. Thank you kindly, Nicolas. On Dec 3, 2007 5:16 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Remember, we both found, independently, that combining separate files yields from a 10-30% performance increase. I have only talked to 2 On synthetic benchmarks. On real apps, which do databases, calculations, network, etc. that would be probably no more than 5%, probably even less. And I don't see any application shipping in this format. This is a very problematic issue - adding a feature into a language that serves only very specific very narrow performance scenario but which will inevitably be widely abused in cases which have nothing to do with that scenario. the feature unnecessary. If you'd like, I could put you in contact with developers who have been struggling with combining files for several years now. Why were they struggling - only problem existing with it is namespaces, and they certainly couldn't try to use namespaces for years? If they had other problems, they will keep having them and multiple namespaces per file are not going to help them. Anecdotally, I heard of a recent file-combining optimization to a very popular CMS that resulted in a 45% performance improvement. Improving Did they use bytecode caching? Anyway, I have hard time believing PHP include is so broken, but if it is - it should be fixed, not through creating syntax-level workarounds but directly. really the only reason not to implement the multiple namespaces per-file I think I described my reasons now multiple times. -- 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] Proposed feature for json_encode()
One thing to consider is changing json_encode to add a header Content-type: application/json (or x-javascript), unless the additional arguments are used.. That way someone using the function to intermingle with HTML will be faced with the fact they have to encode the output, otherwise it breaks the page... Regards Alan Stanislav Malyshev wrote: This is just a different way of encoding Javascript which depending on the context of use will enable Javascript to be embedded securely. Not providing an alternate encoding is a bit like arguing that we shouldn't have base64_encode() because if used incorrectly it could be insecure. I'm not saying not providing, I'm saying we should provide use cases, otherwise this feature will inevitably be misused. We don't have an explanation of when base64_encode() is useful in the Because it's established standard that is widely used. json_encode() option was never used before. base64_encode() uses. Same thing for this json_encode() feature. We can come up with a set of scenarios where we would like to avoid having characters that are meaningful in XML and HTML show up in our json strings. OK, we can. Let's do. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
On Dec 3, 2007, at 2:17 PM, Stanislav Malyshev wrote: I am a developer on a CMS also which uses the auto-include functionality to include many classes over many files. Each request can include up to 30 different files. The speed increase is around the 15% mark when combining the files. This is with APC installed too. Can you provide some benchmark setups that this could be researched - i.e. describe what was benchmarked and how to reproduce it? I've seen this come up before internally at Facebook. Many people do a microtime() test within there code and consider this a definitive benchmark of how fast there script runs. Unfortunately this excludes a lot of work that's done prior to execution. Typically we see people claiming gains from combining files when in actuality they where just excluding the compilation time in their benchmark by moving compilation done via includes() to before the initial script begins executing. When measuring this type of optimization one really must measure outside of PHP using something like an Apache Bench tool so you get an idea of the big picture. I think trying to optimize these also presumes that you're already running a bytecode cache etc. -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] implement stream_set_write_buffer for sockets
I made a wrong assumption in the first patch and although it worked,
stream_set_write_buffer() did return an error.
This one is fixes the return value issue :
--- main/streams/xp_socket.c.orig 2007-12-01 16:56:29.0 +0100
+++ main/streams/xp_socket.c2007-12-03 21:07:02.0 +0100
@@ -254,6 +254,7 @@
int oldmode, flags;
php_netstream_data_t *sock =
(php_netstream_data_t*)stream-abstract;
php_stream_xport_param *xparam;
+ size_t size;
switch(option) {
case PHP_STREAM_OPTION_CHECK_LIVENESS:
@@ -388,6 +389,14 @@
return
PHP_STREAM_OPTION_RETURN_NOTIMPL;
}
+ case PHP_STREAM_OPTION_WRITE_BUFFER:
+ if (ptrparam)
+ size = *(size_t *)ptrparam;
+ else
+ size = CHUNK_SIZE;
+ php_stream_set_chunk_size(stream, size);
+ return PHP_STREAM_OPTION_RETURN_OK;
+
default:
return PHP_STREAM_OPTION_RETURN_NOTIMPL;
}
Hello,
Currently stream_set_write_buffer() only works with file streams. If
used on socket streams it always returns -1 and does nothing. This can
be quite problematic when using datagram sockets because any datagram
bigger than the default 8Kb gets chopped and more than one datagram get
sent, eventually messing up with the receiving side.
This small patch adds support for sockets in stream_set_write_buffer(),
I have tested it and it fixed my problem, but if it needs refinements
i'd be glad to try and help more.
diff against 5.2.5 is here:
http://rectophobia.com/~six/socket_write_buffer.diff
Regards,
Vincent
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
Hi!
Can you provide some benchmark setups that this could be researched -
i.e. describe what was benchmarked and how to reproduce it?
I have already played with this topic. If you don't have an opcode cache
lazy loading is a good solution: it is worth loading a code only when
it is needed. But if you have opcode cache it is worth to put often used
includes into one big file.
I used the following test code:
?php
$measurements = array();
$_GET += array(includeFileCardinality = 9);
$_GET[includeFileCardinality] =
min(max((int)$_GET[includeFileCardinality], 1), 9);
$start = microtime(TRUE);
if ($_GET[includeFileCardinality] =1)
include_once(include.test/flash_config.php);
if ($_GET[includeFileCardinality] =2)
include_once(include.test/access.php);
if ($_GET[includeFileCardinality] =3)
include_once(include.test/awe_config.php);
if ($_GET[includeFileCardinality] =4)
include_once(include.test/functions.php);
if ($_GET[includeFileCardinality] =5)
include_once(include.test/domain_constants.php);
if ($_GET[includeFileCardinality] =6)
include_once(include.test/categories.php);
if ($_GET[includeFileCardinality] =7)
include_once(include.test/config.php);
if ($_GET[includeFileCardinality] =8)
include_once(include.test/common.php);
if ($_GET[includeFileCardinality] =9)
include_once(include.test/errorhandler.lib.php);
$measurements[include - tobb kulon fajl] = microtime(TRUE)-$start;
$start = microtime(TRUE);
include_once(include.test/_all_in_one.php);
$measurements[include - egy nagy fajl] = microtime(TRUE)-$start;
if (php_sapi_name() == cli)
{
echo serialize($measurements);
}
else
{
header(Content-Type: text/html; charset=UTF-8);
displayMeasurments(Eredmények apache modul esetén, $measurements);
displayMeasurments(Eredmények CLI módban,
unserialize(shell_exec(php .__FILE__)));
echo
form
Az egyesével include-olt fájlok száma:br
select name=\includeFileCardinality\ size=\5\
option value=\1\1/option
option value=\2\2/option
option value=\3\3/option
option value=\4\4/option
option value=\5\5/option
option value=\6\6/option
option value=\7\7/option
option value=\8\8/option
option value=\9\9/option
/selectbr
input type=\submit\ value=\Teszt\
/form
;
}
function displayMeasurments($title, $measurements)
{
$fastestTime = min($measurements);
echo table border=\1\\ntrtd colspan=\3\
align=\center\strong.$title./strong/td/tr\n;
foreach($measurements as $testMethod = $elapsedTime)
{
echo trtd.$testMethod./td\n;
echo td.$elapsedTime./td\n;
echo
td.round($elapsedTime/$fastestTime*100).%/td/tr\n\n;
}
echo /table\nbr;
}
?
The files come from a real life project. I get the following result:
Results (apache module)
include - more files0.000619888305664 307%
include - one big file 0.000202178955078 100%
I run the test code a lot of time, I get this characteristics always.
Then I tried the code on heavily IO loaded server (x100 req/sec+DB
replica) and the difference was bigger (5-600%).
Best Regards,
Felhő
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Oriented standard Library
I can certainly see a use for strings as Value Objects, if only for
readability. Chaining a series of methods is much more readable (to me at
least) than wrapping a series of functions. See:
$str = $str-substr(0, 5)-upper()-trim('\n');
vs.
$str = trim(strtoupper(substr(0, 5, $str)), '\n');
That said, the advantage of functions is that you can trivially add your own.
Adding new methods to a class in PHP requires either inheritance (which is
very limiting in many ways) or all sorts of thoroughly weird mechanisms for
sorta implementing mix-ins. I see that as a more limiting factor than using
functions instead of methods.
(Not to say that value objects, auto-boxing, prototype inheritance, and other
semi-functional features aren't cool; I'd love to have more of those in PHP,
but they're a considerably harder problem to solve.)
I would also dispute the idea that everything is a class/object is a
necessary design feature of a mature OO language. It's a design feature of
Java, which is sort of the poster child of classic OO. But Javascript takes
an entirely different, functional-esque approach of everything is an object,
including classes. (Weird but cool.) Python, Perl, and Ruby do their own
weird things. C++ has multiple inheritance. I'm sure there's other
languages I should mention that I am missing, but you get the idea.
Don't make things an object unless there's a reason to. Most of the
OOP features that PHP lacks that would be useful to have are, IMO, the more
functional-esque stuff from Javascript and its ilk, not classes-all-around.
On Monday 03 December 2007, Jordan Wambaugh wrote:
Thanks. I was not aware of SPL's file and array classes. As for the string
class, some of it is done, and should work in 5.x HEAD. I fully plan to add
Unicode support for PHP 6's HEAD. Is there any other concerns you may have
about a string class (other than it being a big task)? I think it would be
great to unify, and standardize all the string functions in PHP into a
class.
I don't want to rewrite anything already written, so I'll go ahead and take
a look at ArrayObject and ArrayIterator. I'd love to help PHP as much as
possible.
Thanks,
Jordan.
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 12:18 PM
To: Jordan Wambaugh
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Object Oriented standard Library
Hello Jordan,
have a look at the SPL extension (Standard PHP Library) which introduces
a few things (for instance SplFile). Have a look here:
http://php.net/~helly I do not think we need a string class right now
unless you want to provide a full unicode one that later works with HEAD
seamingly. If you are intersted, then the ArrayObject/ArrayIterator
implementation in SPL can be made much faster. I know what to do but have
no time for that...
and as always, help is always welcome here
and if you have something to show, then show us :-)
marcus
Monday, December 3, 2007, 5:43:19 PM, you wrote:
I am currently working on a Object-Oriented Library extension that wraps
a lot of functionality in PHP's standard library dealing with strings,
arrays, fileIO, etc. into classes.
(String class, Collection class, etc.)
This would allow end-users to create objects that represent data types
and resources, and take advantage of all the benefits of OOP (object
chaining, polymorphism, etc) all in a c compiled extension.
Example:
$myString=new String(Hello world!);
$myLowerCaseString =
$myString-copy()-replace(world,universe)-lowerCase();
The goal of this project is to help PHP mature into a more
object-oriented language with an object oriented library, while
addressing a common complaint about the standard library not being very
consistent
(http://en.wikipedia.org/wiki/Php#Criticism [8th bullet])
I have already implemented a couple classes, but would like to get
feedback
from the PHP development community on the idea of creating such a library
for PHP. Also, any suggestions would be greatly appreciated.
Thanks,
Jordan Wambaugh
Best regards,
Marcus
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
Alan Knowles wrote:
One thing to consider is changing json_encode to add a header
Content-type: application/json (or x-javascript), unless the additional
arguments are used..
That way someone using the function to intermingle with HTML will be
faced with the fact they have to encode the output, otherwise it breaks
the page...
Now that sounds downright disruptive, and all the tutorials will say:
Use json_encode('foobar', NO_HEADERS) because the other way does weird
stuff to PHP scripts. :-)
--
Edward Z. YangGnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
2007/12/3, Ilia Alshanetsky [EMAIL PROTECTED]: I think the patch does have a value, yes, it does, what worries me is the introduction of yet another non-sense ini setting that modified the very engine behaviuor.. I think we all agree that there are way too many of those do we ? . My suggestion is that we make this feature a compile time flag. My suggestion is not to add any compile time flag, either provide it or dont. and people who feel that their applications warrant a garbage collector can enable it for their install and at the same time those who don't (general case) have no penalties of having it in place. People more commonly uses PHP from distributors, in binary form.. they dont usually decide what is enabled or not, so you have to either reccommend this feature or mark it clearly as untrusted, experimental. such switches only add more complexity, confusion for users and addtional trouble to distributors. my 2CLP. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
First of all big thanks for Dmitry and David for spending time on this project and continuing to improve the original patch. Based on the results so far, I think the patch does have a value, but certainly not in a general case. Relative simple scripts have little to gain from it and only to loose 3-5% of speed depending on a situation and given insubstantial memory gains it seems of little use in general case. That said, there are complex applications (perhaps unnecessarily so ;-) ) that could see some real benefits from this code. My suggestion is that we make this feature a compile time flag, that's off by default and people who feel that their applications warrant a garbage collector can enable it for their install and at the same time those who don't (general case) have no penalties of having it in place. On 3-Dec-07, at 4:01 PM, Andi Gutmans wrote: Hi all, Was hoping to send this off earlier but I was travelling for the past week and had very limited email access. As promised in the past few weeks we have spent a significant amount of time in reviewing the garbage collector work and testing it in our performance lab. Dmitry has been exchanging ideas and patches with David Wang during this time. Suffice to say that as I've mentioned in the past, memory management is an extremely sensitive piece of PHP, which is why it was important for us to review this work in great depth before committing it to the code base. The updated patch still retains the same algorithm as David's original implementation however the data structures have been changed in order to work faster and use less memory. The revised patch has the following advantages: - It fixes several crash bugs - Enhances performance by removing several unnecessary checks - The memory overhead was reduced (from 12 to 4 bytes for each heap-allocated zval) - The speed of clean PHP code (code that doesn't create cycles) was improved - Additional test cases were created The end result is a more stable and faster GC patch. That said we have yet to find real-life applications that create significant cycles which would benefit from this patch. In fact as you'll see from the results our tests show an increase in maximum memory use and slower execution (to be fair they are marginal). We have tested both PHP_5_3 without any patches, the original patch and the new patch. The following table shows execution time (seconds for N requests) and slowdown. PHP_5_3 Original GC patch Current GC patch slowdown slowdown bench 11,550 12,310 6,58% 12,170 5,37% hello 8,781 8,852 0,81% 8,813 0,36% xoops 128,500 135,100 5,14% 130,200 1,32% static 18,540 20,840 12,41% 18,920 2,05% qdig 29,320 30,270 3,24% 29,610 0,99% qdig2 13,960 14,100 1,00% 14,090 0,93% The next table shows memory usage in MB and overhead PHP_5_3 Original GC patch Current GC patch overhead overhead hello 13,750 13,945 1,42% 13,765 0,11% xoops 18,036 18,636 3,33% 18,568 2,95% static 15,300 16,000 4,58% 15,308 0,05% qdig 14,820 15,008 1,27% 14,828 0,05% qdig2 14,824 15,012 1,27% 14,838 0,09% To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). We also tested SugarCRM to get another sanity for these results and we got similar results. I am not quite sure where this leaves us with this patch. On one hand I think now the effort has been made it's a good thing to offer it as part of PHP. The downside is of course some performance degradation and possible instabilities as this patch continues to stabilize (it took about two releases for us to stabilize the Zend Memory Manager even after in-depth testing due to edge cases in allocation patterns and various extensions, etc...).I'd be surprised if our team has found all possible bugs. Personally I think the decision should be either in or out. Adding this as a compile option is not a good idea as it would create binary compatibility issues and would be a pain for the community. I think my inclination is to commit the patch, not have it #ifdef'ed but always compiled but to have the garbage collection itself turned off by default (mainly for stability reasons. Note: the increased memory footprint and performance loss also exists with the collection itself turned off). We can turn it on when we're in dev for snapshots so that we iron out bugs. That said, as you can see from the results most people and real-life applications will be worse off than today. Thanks to David Dmitry for working hard on this (and everyone else who contributed). The stage is open for ideas/thoughts/suggestions J Andi Ilia Alshanetsky -- PHP Internals - PHP
Re: [PHP-DEV] Garbage collector patch
such switches only add more complexity, confusion for users and addtional trouble to distributors. FWIW, amen to that. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
One thing to consider is changing json_encode to add a header
Content-type: application/json (or x-javascript), unless the additional
arguments are used..
That way someone using the function to intermingle with HTML will be
faced with the fact they have to encode the output, otherwise it breaks
the page...
ob_iconv_handler() does something similar to this and I consider it a
mistake as:
ob_start('ob_iconv_handler');
echo Foo;
ob_flush();
echo Bar;
Will result in a headers already sent message, even though no explicit
attempt is made to send headers.
I've been meaning to come up with a BC fix for this... In time for 5.3
at least...
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
Brian Shire wrote: On Dec 3, 2007, at 2:17 PM, Stanislav Malyshev wrote: I am a developer on a CMS also which uses the auto-include functionality to include many classes over many files. Each request can include up to 30 different files. The speed increase is around the 15% mark when combining the files. This is with APC installed too. Can you provide some benchmark setups that this could be researched - i.e. describe what was benchmarked and how to reproduce it? I've seen this come up before internally at Facebook. Many people do a microtime() test within there code and consider this a definitive benchmark of how fast there script runs. Unfortunately this excludes a lot of work that's done prior to execution. Typically we see people claiming gains from combining files when in actuality they where just excluding the compilation time in their benchmark by moving compilation done via includes() to before the initial script begins executing. When measuring this type of optimization one really must measure outside of PHP using something like an Apache Bench tool so you get an idea of the big picture. I think trying to optimize these also presumes that you're already running a bytecode cache etc. Hi Brian and Stas, I hate to say it, but it is somewhat condescending to assume that the benchmarks were done with microtime(). I spent about 15 hours of my time designing a very complex, carefully constructed benchmark, and yes, I ran it with apache benchmark. In addition, I ran the benchmark using no APC, with APC, and with APC and apc.stat=0. The benchmark in question compared require_once to include with full paths to a single file. In the best case, I got a 12% performance difference between include with full paths and apc.stat=0 and a single file. An earlier benchmark compared a single file to using both require_once and dirname(__FILE__) - a real performance killer that resulted in 19% difference without APC, and 30% difference with APC. Oh and before anyone gets any ideas about my competence, Stas tried the same benchmark in Zend's ultra-high tech lab and got the same results. These are not some loser's microtime() benchmark. What is particularly irksome about this whole nightmare is the combination of prove it you little peon attitude and the fact that it doesn't really matter what evidence this little peon presents - the decision appears to have already been made without any debate or interest in work. At first I thought it was the annoyance of having to come up with a patch, but I have also provided patches complete with .phpt tests. If the decision is to ignore input, I would really rather someone just say piss off instead of letting me waste several months patiently proving that there *is* a performance difference that can matter just so that it can be dismissed without consideration and vague references to it probably is really only a 5% difference. Then I wouldn't have to waste more time writing messages like this one that say: I've already proven there's a performance difference, the ball is in *your* court to prove (with benchmark) that I am wrong. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Dec 3, 2007, at 1:01 PM, Andi Gutmans wrote: Hi all, Was hoping to send this off earlier but I was travelling for the past week and had very limited email access. As promised in the past few weeks we have spent a significant amount of time in reviewing the garbage collector work and testing it in our performance lab. Dmitry has been exchanging ideas and patches with David Wang during this time. Suffice to say that as I've mentioned in the past, memory management is an extremely sensitive piece of PHP, which is why it was important for us to review this work in great depth before committing it to the code base. The updated patch still retains the same algorithm as David's original implementation however the data structures have been changed in order to work faster and use less memory. ... Personally I think the decision should be either in or out. Adding this as a compile option is not a good idea as it would create binary compatibility issues and would be a pain for the community. ... The stage is open for ideas/thoughts/suggestions I'm really hesitant to even *mention* this idea, but Could alternate memory management systems be made available via PECL add-ons, or, more to the point: What is the *actual cost and complexity* involved in implementing (possibly many) different user-selectable memory management systems, and what other future benefits/drawbacks might we see by doing such a thing? (GC is big now, but what about memory pools per mod_auth user, or SHM/SEM pools, or tuning amounts of memory per function, etc...) I will now apologize to everybody who I just made cry, scream, or damage their furniture, as I didn't mean to hurt you, just trying to stimulate ideas. -Ronabop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
-Original Message- From: Ronald Chmara [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 10:06 PM To: Andi Gutmans Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch I'm really hesitant to even *mention* this idea, but Could alternate memory management systems be made available via PECL add-ons, or, more to the point: What is the *actual cost and complexity* involved in implementing (possibly many) different user-selectable memory management systems, and what other future benefits/drawbacks might we see by doing such a thing? (GC is big now, but what about memory pools per mod_auth user, or SHM/SEM pools, or tuning amounts of memory per function, etc...) I will now apologize to everybody who I just made cry, scream, or damage their furniture, as I didn't mean to hurt you, just trying to stimulate ideas. Hi Ronald, PHP 5.2.x already supports the ability to hook in different page managers. In PHP 5.3 you can also override the memory allocation functions. However, this would not include garbage collection like algorithms which actually require changes in the core PHP data type such as zvals. In fact the garbage collection adds memory to the basic datatypes which is why I suggested to either always make these changes, or don't make them so that we retain binary compatibility across all builds of PHP. So overriding basic memory allocation functions, yes, ability to provide various GC implementations, no. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ignored patches
On Dec 3, 2007, at 9:16 PM, Gregory Beaver wrote: Brian Shire wrote: On Dec 3, 2007, at 2:17 PM, Stanislav Malyshev wrote: I am a developer on a CMS also which uses the auto-include functionality to include many classes over many files. Each request can include up to 30 different files. The speed increase is around the 15% mark when combining the files. This is with APC installed too. Can you provide some benchmark setups that this could be researched - i.e. describe what was benchmarked and how to reproduce it? I've seen this come up before internally at Facebook. Many people do a microtime() test within there code and consider this a definitive benchmark of how fast there script runs. Unfortunately this excludes a lot of work that's done prior to execution. Typically we see people claiming gains from combining files when in actuality they where just excluding the compilation time in their benchmark by moving compilation done via includes() to before the initial script begins executing. When measuring this type of optimization one really must measure outside of PHP using something like an Apache Bench tool so you get an idea of the big picture. I think trying to optimize these also presumes that you're already running a bytecode cache etc. Hi Brian and Stas, I hate to say it, but it is somewhat condescending to assume that the benchmarks were done with microtime(). I spent about 15 hours of my time designing a very complex, carefully constructed benchmark, and yes, I ran it with apache benchmark. In addition, I ran the benchmark using no APC, with APC, and with APC and apc.stat=0. The benchmark in question compared require_once to include with full paths to a single file. In the best case, I got a 12% performance difference between include with full paths and apc.stat=0 and a single file. Hi Greg, I'm sorry that my message probably did come off as condescending. :- ( I really just wanted to share some my *own* pitfalls in case it was something that might be helpful here. If you aren't too put off and you are running APC then perhaps we can discuss more off-list as some of our performance problems may be similar and I could exchange some optimizations with you to try out. Again *extremely* sorry for insulting you or anyone else here with my not so well thought out email, I'd just like to try to help out a bit. -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
On Dec 3, 2007, at 10:30 PM, Andi Gutmans wrote: -Original Message- From: Ronald Chmara [mailto:[EMAIL PROTECTED] What is the *actual cost and complexity* involved in implementing (possibly many) different user-selectable memory management systems, and what other future benefits/drawbacks might we see by doing such a thing? (GC is big now, but what about memory pools per mod_auth user, or SHM/SEM pools, or tuning amounts of memory per function, etc...) I will now apologize to everybody who I just made cry, scream, or damage their furniture, as I didn't mean to hurt you, just trying to stimulate ideas. Hi Ronald, PHP 5.2.x already supports the ability to hook in different page managers. In PHP 5.3 you can also override the memory allocation functions. However, this would not include garbage collection like algorithms which actually require changes in the core PHP data type such as zvals. In fact the garbage collection adds memory to the basic datatypes which is why I suggested to either always make these changes, or don't make them so that we retain binary compatibility across all builds of PHP. So overriding basic memory allocation functions, yes, ability to provide various GC implementations, no. Okay, so, without this patch, I can allocate mem, and destroy it, on a per page level, but not on a zval level, and the choice is: a) zval (etc.) destruction with this patch, which has a 5% speed hit at times (varies per test) b) no patch, no change c) something which hasn't been thought of yet? I'd have to (sadly) ask that anything that slows down PHP by 5%, to improve performance for programmers that, uhm, leak or otherwise gobble RAM, that they, uhm, refactor their code as professional programmers. Thanks for clearing it up for me, Andi. -Bop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
