Re: [PHP-DEV] SVN Account Request: lytboris
On Mon, Jan 31, 2011 at 09:37, Lytochkin Boris lytbo...@gmail.com wrote: Hi. On Fri, Jan 28, 2011 at 11:46 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Your SVN account is enabled and you have karma for php/php-src/*/ext/snmp,phpdoc It seems I need rw for NEWS :) Access denied: Insufficient karma for lytboris to php/php-src/branches/PHP_5_2/NEWS. Contact gr...@php.net for access. Can you help with this issue? No.. I don't have karma to give karma. But I'm sure someone on this list can :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend mm
Am 31.01.2011 01:45, schrieb Ben Schmidt: - Relating this to, PHP: PHP is a garbage collected language which I believe uses reference counting and a clever collector to detect and free cycles. I haven't looked in detail into the implementation, but I know some documentation is available on the subject here: http://www.php.net/manual/en/features.gc.php http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf is the algorithm used by PHP's garbage collector. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
hi Rasmus, On Mon, Jan 31, 2011 at 5:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: Aren't Apache VC9 builds readily available these days? http://www.apachelounge.com/download/ We can't keep supporting what is now a 13-year old compiler. As I said earlier already, we won't support VC6 any longer (the fpu bug forced to take this decision :). However this is not the only problem there (or in some other extensions). Lack of clean casting (leaving the decision to the compiler(s) is not a good thing) or bad API usage (floor != floorf) and other related mistakes can be fixed easily and we do fix them in most of the php code, except in date where it is slightly harder to get obvious things fixed. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: lytboris
hi, On Fri, Jan 28, 2011 at 8:49 AM, Lytochkin Boris lytbo...@gmail.com wrote: Hi. Well, I have no karma still actually. I sent an e-mail to gr...@php.net a week ago but have no answer still. Can anybody help me fixing my SVN account? Added NEWS to your karma, that would not have prevented you to commit the patches tho' :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
hi, On Mon, Jan 31, 2011 at 5:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: Aren't Apache VC9 builds readily available these days? http://www.apachelounge.com/download/ I forgot to mention it here again. These builds are not officially supported by Apache but work very well. Apache still uses VC6 (vc6 crt or compiler) for their releases. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zend engine's hashtable performance tweaks
Hello, I've managed to change my patch to merge against trunk, there were some problems with interned strings optimization. I've created bug report with new patch: http://bugs.php.net/bug.php?id=53866 I've changed hashing function again, it looks like working better than previous, but nothings proven. What's to be done (this is listed also in bug report): - http://lxr.php.net/xref/PHP_TRUNK/ext/standard/html_tables/html_table_gen.php#722 should be changed and html_tables.h regenerated, but this will need to rewrite hashtable engine from C to PHP, - APC should be fixed. Hi Marcin, Can you mail the PHP Internals list and also the apc-...@lists.php.net list when you have logged the bug? I mentioned your patches to Gopal, the APC maintainer, and he was interested to see what was needed. Regards, Chris On 01/11/2011 04:28 PM, Marcin Babij wrote: Hello, I merge patch with trunk, do some things already proposed, and I'll create bug report with patch for trunk in 1, 2 weeks most. On 12/31/2010 10:15 AM, Pierre Joye wrote: hi, Thanks for the patches :) Can you open a bug report please (and attach the patches to it)? I'm sure this patch will be updated a couple of times before it reaches the repository. Cheers, Hi Marcin, Did you log a bug for this? Regards, Chris On Fri, Dec 31, 2010 at 4:58 PM, Marcin Babij marcin.ba...@nasza-klasa.pl wrote: Sorry for no attachments in previous message, I think my attachments weren't redirected with message by lists.php.net email confirmation system. I send them again, and for sure I attach links to public copy of them over HTTP: https://gist.github.com/761094 - php-5.3.4-hashtable-optimization.patch https://gist.github.com/761096 - apc-3.1.6-hashtable-optimization.patch Hello, I work for social network company, where we were running optimization project. One of it's results is patch to Zend engine's Hashtable, which we want to share and ask you for comments and improvements. Why we do this? We run profiling on our production servers and found out that zend_hash_* functions take 10-20% CPU time of request. So there is some room for easy improvements. What was done? - Hash function in zend_hash.h was rebuilt and became much faster, without losing the most important properties. - Hashtable implementation was changed from Simple chaining to Open addressing with linear probing, but with linked bucket, not included in hash array, which causes: -- Bucket structure to lose 2 pointers. -- Searching works similar, but don't have to jump with pointers stored in different memory locations, inserting, deleting and rehashing don't need to update linked list, but must search for first empty bucket, which is fast, because it scans continuous memory. -- Load factor decreases from 1.0 to 0.5-0.75 to make less collisions and faster hashtable, which in turn increases memory footprint a little. - Open addressing doesn't change significantly performance, but next thing was to create new array (arEmpty), which is of size nTableSize bytes, which keeps track of used/empty buckets and makes inserting and rehashing much faster. In future it can be tested as bit-array with size of nTableSize/8 bytes. - More macros were added to replace repetitive constructs. - New constants were added to allow: -- Creating new hashtables of size at least X (where 4 and 8 are reasonable), which makes no rehashing and reallocing memory while changing size to 2 and then to 4. -- For small tables it's better to extend them by a factor of 4 times, not 2, to make rehashing cost smaller for most hashtables, of cost of little higher memory consumption. -- For large tables it's better to have other load factor, closer to 1, while for small tables it's better to use load factor closer to 0.5. - APC was patched to take changes in Bucket structure into account. How was it tested? It was tested with make test, where one more (comparing to original sources) test fails, but it's most probably because http://bugs.php.net/bug.php?id=48858 - IMO test is badly constructed (is too simple) and any change of hashing function makes it fail. Also it was tested on our testing environment and production servers against30mln requests to our site, with 120requests/s at peak on Xeon @ 2.50GHz with 8GB RAM running Debian Linux. What is the gain? After tests CPU usage dropped by about 4% -6%. Memory footprint goes up just by few percent. What can be done in future? - Make new constants configurable by php.ini. - Test if changing arEmpty from byte-array to bit-array helps on performance. - Tweak default constants' values using some real-live benchmarks. - Prove (or modify and prove) hash function to have property, that it has no collisions if two keys don't differ on no more than 6 bytes, which will lead to memcmp omit first (or last) 6 bytes of key. Also simpler thing may be proven, that is it has no collisions if two keys are not
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On 1/30/2011 5:02 PM, Stas Malyshev wrote: It looks like all of these are reproducible only on vc6 build and all have same issues with division and rounding, and all not reproducible on vc9 - which makes me thing it's some vc6 problem. Maybe the one Gustavo identified, or something like it. I'd be inclined to say recommendation for it would be to build it on vc9. Why wouldn't you address this with VC10? Is there some reason to use the already stale n-1 version? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On 1/30/2011 10:36 PM, Rasmus Lerdorf wrote: On 1/30/11 8:30 PM, Daniel Convissor wrote: That's not an option for the large number of people who want to run PHP under Apache, let alone folks who don't have VC9 tools. The diff() code is mauling data types in undesirable, though easily fixable, ways. Aren't Apache VC9 builds readily available these days? From all I've heard, mod_fcgid is the way to go anyways, so isn't the whole discussion academic? It doesn't matter how php is built if you are loading the appropriate number of single process instances as fastcgi daemons. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] implicit reference
I am migrating a huge php 4 system to php 5.3. I need something like a op override for the = operator. I'm working on a script with lots of ER + token_get_all but its also a hard work. Any suggestion ? I dont want refereces.. except in explicit cases and i need to use php 5.3
Re: [PHP-DEV] implicit reference
On Mon, Jan 31, 2011 at 6:38 PM, Mathias Grimm mathiasgr...@gmail.comwrote: I am migrating a huge php 4 system to php 5.3. I need something like a op override for the = operator. I'm working on a script with lots of ER + token_get_all but its also a hard work. Any suggestion ? I dont want refereces.. except in explicit cases and i need to use php 5.3 hi it would be a better to migrate the project to using cloning where neccessary http://php.net/manual/en/language.oop5.cloning.php but until that, you can use some hack like http://pecl.php.net/package/operator (don't know if it works with 5.3) Tyrael
Re: [PHP-DEV] implicit reference
On Mon, Jan 31, 2011 at 6:45 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Mon, Jan 31, 2011 at 6:38 PM, Mathias Grimm mathiasgr...@gmail.comwrote: I am migrating a huge php 4 system to php 5.3. I need something like a op override for the = operator. I'm working on a script with lots of ER + token_get_all but its also a hard work. Any suggestion ? I dont want refereces.. except in explicit cases and i need to use php 5.3 hi it would be a better to migrate the project to using cloning where neccessary http://php.net/manual/en/language.oop5.cloning.php but until that, you can use some hack like http://pecl.php.net/package/operator (don't know if it works with 5.3) Tyrael and for the record, we had a config to turn back that behavior in php5, but that was removed with 5.3: http://www.php.net/manual/en/ini.core.php#ini.zend.ze1-compatibility-mode Tyrael
Re: [PHP-DEV] implicit reference
thanks, there is no = operator overloading =( On Mon, Jan 31, 2011 at 3:47 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Mon, Jan 31, 2011 at 6:45 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Mon, Jan 31, 2011 at 6:38 PM, Mathias Grimm mathiasgr...@gmail.comwrote: I am migrating a huge php 4 system to php 5.3. I need something like a op override for the = operator. I'm working on a script with lots of ER + token_get_all but its also a hard work. Any suggestion ? I dont want refereces.. except in explicit cases and i need to use php 5.3 hi it would be a better to migrate the project to using cloning where neccessary http://php.net/manual/en/language.oop5.cloning.php but until that, you can use some hack like http://pecl.php.net/package/operator (don't know if it works with 5.3) Tyrael and for the record, we had a config to turn back that behavior in php5, but that was removed with 5.3: http://www.php.net/manual/en/ini.core.php#ini.zend.ze1-compatibility-mode Tyrael
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On 1/31/2011 5:23 AM, Pierre Joye wrote: hi, On Mon, Jan 31, 2011 at 5:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: Aren't Apache VC9 builds readily available these days? http://www.apachelounge.com/download/ I forgot to mention it here again. These builds are not officially supported by Apache but work very well. Apache still uses VC6 (vc6 crt or compiler) for their releases. Or to say the same thing with different words, the ASF doesn't release binaries at all, they release source code. AFAIK apachelounge builds come together with no issues from the released source packages, although there is sometimes a small delay when they find a flaw, fix, and submit the fix upstream. But this doesn't really differ from any other linux distributor who ships httpd :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On Mon, Jan 31, 2011 at 6:26 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/30/2011 5:02 PM, Stas Malyshev wrote: It looks like all of these are reproducible only on vc6 build and all have same issues with division and rounding, and all not reproducible on vc9 - which makes me thing it's some vc6 problem. Maybe the one Gustavo identified, or something like it. I'd be inclined to say recommendation for it would be to build it on vc9. Why wouldn't you address this with VC10? Is there some reason to use the already stale n-1 version? It does not matter what is the latest VC version. What matters is that VC6 is a dead cow and we won't support it anymore, even for the current stable, 5.3. And to be honest I don't really care about Apache.org's users (as in sticking to VC6) as they have a solution already, apachelounge.com. Apache based wamp/xamp and co can migrate easily as well. I also plan to support them in this move to unify as long as we can our builds, to avoid conflicts with the numerous available builds. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On Mon, Jan 31, 2011 at 6:28 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/30/2011 10:36 PM, Rasmus Lerdorf wrote: On 1/30/11 8:30 PM, Daniel Convissor wrote: That's not an option for the large number of people who want to run PHP under Apache, let alone folks who don't have VC9 tools. The diff() code is mauling data types in undesirable, though easily fixable, ways. Aren't Apache VC9 builds readily available these days? From all I've heard, mod_fcgid is the way to go anyways, so isn't the whole discussion academic? It doesn't matter how php is built if you are loading the appropriate number of single process instances as fastcgi daemons. If the goal is to get something somehow stable, but horrible (performance and ability to use some windows APIs) from a design point of view for the windows platform, then yes, fcgi is the way to go and not necessary with apache then (IIS, nginx are way better choices in this case). But I strongly believe in a threaded base solution for windows. That's the only way to get anywhere close to the performance we can see on other platforms (read: posix). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On 1/31/2011 1:43 PM, Pierre Joye wrote: On Mon, Jan 31, 2011 at 6:26 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/30/2011 5:02 PM, Stas Malyshev wrote: It looks like all of these are reproducible only on vc6 build and all have same issues with division and rounding, and all not reproducible on vc9 - which makes me thing it's some vc6 problem. Maybe the one Gustavo identified, or something like it. I'd be inclined to say recommendation for it would be to build it on vc9. Why wouldn't you address this with VC10? Is there some reason to use the already stale n-1 version? It does not matter what is the latest VC version. What matters is that VC6 is a dead cow and we won't support it anymore, [..] Which I think we agree with, but you answer is a non sequitur, if you are defining the 'next right solution', why deploy the n-1 build environment? You would just be applying that legacy to the next maintainer, whom like you, will ask you why they need to be dealing with VC 9 :) As a complete aside, Mladen reminds us on the httpd dev list that the Sun JDK's are built with VC 2003, and my other two data points were always what ActiveState offered for perl and python (and now, of course, what the strawberry perl offers). So while I'm not insensitive to the PHP community, those are the four major languages that could be deployed in-process which can suffer all sorts of incompatibility with one another, and with httpd itself :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] implicit reference
hi, On Mon, Jan 31, 2011 at 6:38 PM, Mathias Grimm mathiasgr...@gmail.com wrote: I dont want refereces.. except in explicit cases and i need to use php 5.3 References have been abused in all possible and impossible ways. What are the exact cases where you need to do it? Maybe it is already treated as reference anyway (like obj as argument for a function/method). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] implicit reference
On Mon, Jan 31, 2011 at 8:53 PM, Pierre Joye pierre@gmail.com wrote: hi, On Mon, Jan 31, 2011 at 6:38 PM, Mathias Grimm mathiasgr...@gmail.com wrote: I dont want refereces.. except in explicit cases and i need to use php 5.3 References have been abused in all possible and impossible ways. What are the exact cases where you need to do it? Maybe it is already treated as reference anyway (like obj as argument for a function/method). I think he is hit by this backward incompatible change: http://www.php.net/manual/en/migration5.oop.php http://www.php.net/manual/en/migration5.oop.php imo migrating a fairly large php app from php 4 to 5.3 isn't exactly like a walk in the park Tyrael
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On Mon, Jan 31, 2011 at 8:52 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Which I think we agree with, but you answer is a non sequitur, if you are defining the 'next right solution', why deploy the n-1 build environment? I did not refer to the next right solution but the current and actual right solution, for PHP 5.3. We did not decide yet what to do with 5.3 but as trunk builds just fine for 9 or 10, that's not a big deal yet. I will post more on that in the next weeks. x64 support may also affect the choice. But I fear that to make our code base x64 friendly on windows (and consequently cleaner on other platforms) will require way too much political debate like this one (which was one of the most pointless discussion in internals history, until it moved to the vc6 vs vcN :)... You would just be applying that legacy to the next maintainer, whom like you, will ask you why they need to be dealing with VC 9 :) We have to keep in mind that the 2008 serie will be maintained for the next decade or so, no worry there. However as I said previously, no decision has been taken yet for php-next. As a complete aside, Mladen reminds us on the httpd dev list that the Sun JDK's are built with VC 2003, and my other two data points were always what ActiveState offered for perl and python (and now, of course, what the strawberry perl offers). So while I'm not insensitive to the PHP community, those are the four major languages that could be deployed in-process which can suffer all sorts of incompatibility with one another, and with httpd itself :) As far as I remember the JDK is crt independent. No idea about the other. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] implicit reference
the constraint is that all need to run on php4.3.6 and 5.3
I have one function called my_clone($obj) {} , if is php5 it is serialized
and deserialized (to clone member recursively), if php4 just return the
parameter.
In first moment Im migrating all assignments to use my_clone and later
manual update each one. im ignoring some obvious assignments like strings,
concatenation, constants and so on.
The system have about 3 million of php 4.3.6 lines, no way to manual
migrating.
By now im mixing ER + token_get_all but is like build a parser...
On Mon, Jan 31, 2011 at 5:53 PM, Pierre Joye pierre@gmail.com wrote:
hi,
On Mon, Jan 31, 2011 at 6:38 PM, Mathias Grimm mathiasgr...@gmail.com
wrote:
I dont want refereces.. except in explicit cases and i need to use php
5.3
References have been abused in all possible and impossible ways.
What are the exact cases where you need to do it? Maybe it is already
treated as reference anyway (like obj as argument for a
function/method).
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Re: [PHP-DEV] implicit reference
On Mon, Jan 31, 2011 at 9:08 PM, Mathias Grimm mathiasgr...@gmail.com wrote: the constraint is that all need to run on php4.3.6 and 5.3 You may not have the choice but that's simply a very bad idea. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On Mon, Jan 31, 2011 at 9:21 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/31/2011 2:04 PM, Pierre Joye wrote: On Mon, Jan 31, 2011 at 8:52 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Which I think we agree with, but you answer is a non sequitur, if you are defining the 'next right solution', why deploy the n-1 build environment? I did not refer to the next right solution but the current and actual right solution, for PHP 5.3. We did not decide yet what to do with 5.3 but as trunk builds just fine for 9 or 10, that's not a big deal yet. I will post more on that in the next weeks. x64 support may also affect the choice. But I fear that to make our code base x64 friendly on windows (and consequently cleaner on other platforms) will require way too much political debate like this one Political? yes, see the origin of this thread. No, what it will require is for all the dependent libraries to build and function properly on a 64P architecture; the vast majority of PHP's libraries are now 64LP or 64ILP safe, but there is still a ton of legacy code expecting void *vp = (void*)lval; and long lval = (long)vp sorts of foolishness to work :( That will be no small challenge. To port the libraries when necessary is the smallest issue for me (so far most of them worked, last was ssh2 and we fixed the crash recently, latest pgsql supports win64 too, for example :). To argue about each commit in php-src because it works for me with gcc so don't change it is what will kill all the possible fun. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] implicit reference
Ow, what a crap idea ... You want to make the same php4-written source code run with PHP4 AND PHP5.3 ? That seems like an unsolvable challenge, I think that even if you dont mind very bad codes/stuff you won't make it fully work for production without alarms every minutes ... Good luck, Julien On Mon, Jan 31, 2011 at 9:10 PM, Pierre Joye pierre@gmail.com wrote: On Mon, Jan 31, 2011 at 9:08 PM, Mathias Grimm mathiasgr...@gmail.com wrote: the constraint is that all need to run on php4.3.6 and 5.3 You may not have the choice but that's simply a very bad idea. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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] REMOVE : [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.ctrunk/ext/date/php_date.c
REMOVE - Original Message - From: William A. Rowe Jr. [mailto:wr...@rowe-clan.net] To: internals@lists.php.net Sent: Mon, 31 Jan 2011 11:28:19 -0600 Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.ctrunk/ext/date/php_date.c On 1/30/2011 10:36 PM, Rasmus Lerdorf wrote: On 1/30/11 8:30 PM, Daniel Convissor wrote: That's not an option for the large number of people who want to run PHP under Apache, let alone folks who don't have VC9 tools. The diff() code is mauling data types in undesirable, though easily fixable, ways. Aren't Apache VC9 builds readily available these days? From all I've heard, mod_fcgid is the way to go anyways, so isn't the whole discussion academic? It doesn't matter how php is built if you are loading the appropriate number of single process instances as fastcgi daemons. -- 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] REMOVE : [PHP-DEV] Re: Zend engine's hashtable performance tweaks
REMOVE - Original Message - From: Marcin Babij [mailto:marcin.ba...@nasza-klasa.pl] To: internals@lists.php.net,apc-...@lists.php.net Sent: Mon, 31 Jan 2011 12:35:53 +0100 Subject: Re: [PHP-DEV] Re: Zend engine's hashtable performance tweaks Hello, I've managed to change my patch to merge against trunk, there were some problems with interned strings optimization. I've created bug report with new patch: http://bugs.php.net/bug.php?id=53866 I've changed hashing function again, it looks like working better than previous, but nothings proven. What's to be done (this is listed also in bug report): - http://lxr.php.net/xref/PHP_TRUNK/ext/standard/html_tables/html_table_gen.php#722 should be changed and html_tables.h regenerated, but this will need to rewrite hashtable engine from C to PHP, - APC should be fixed. Hi Marcin, Can you mail the PHP Internals list and also the apc-...@lists.php.net list when you have logged the bug? I mentioned your patches to Gopal, the APC maintainer, and he was interested to see what was needed. Regards, Chris On 01/11/2011 04:28 PM, Marcin Babij wrote: Hello, I merge patch with trunk, do some things already proposed, and I'll create bug report with patch for trunk in 1, 2 weeks most. On 12/31/2010 10:15 AM, Pierre Joye wrote: hi, Thanks for the patches :) Can you open a bug report please (and attach the patches to it)? I'm sure this patch will be updated a couple of times before it reaches the repository. Cheers, Hi Marcin, Did you log a bug for this? Regards, Chris On Fri, Dec 31, 2010 at 4:58 PM, Marcin Babij marcin.ba...@nasza-klasa.pl wrote: Sorry for no attachments in previous message, I think my attachments weren't redirected with message by lists.php.net email confirmation system. I send them again, and for sure I attach links to public copy of them over HTTP: https://gist.github.com/761094 - php-5.3.4-hashtable-optimization.patch https://gist.github.com/761096 - apc-3.1.6-hashtable-optimization.patch Hello, I work for social network company, where we were running optimization project. One of it's results is patch to Zend engine's Hashtable, which we want to share and ask you for comments and improvements. Why we do this? We run profiling on our production servers and found out that zend_hash_* functions take 10-20% CPU time of request. So there is some room for easy improvements. What was done? - Hash function in zend_hash.h was rebuilt and became much faster, without losing the most important properties. - Hashtable implementation was changed from Simple chaining to Open addressing with linear probing, but with linked bucket, not included in hash array, which causes: -- Bucket structure to lose 2 pointers. -- Searching works similar, but don't have to jump with pointers stored in different memory locations, inserting, deleting and rehashing don't need to update linked list, but must search for first empty bucket, which is fast, because it scans continuous memory. -- Load factor decreases from 1.0 to 0.5-0.75 to make less collisions and faster hashtable, which in turn increases memory footprint a little. - Open addressing doesn't change significantly performance, but next thing was to create new array (arEmpty), which is of size nTableSize bytes, which keeps track of used/empty buckets and makes inserting and rehashing much faster. In future it can be tested as bit-array with size of nTableSize/8 bytes. - More macros were added to replace repetitive constructs. - New constants were added to allow: -- Creating new hashtables of size at least X (where 4 and 8 are reasonable), which makes no rehashing and reallocing memory while changing size to 2 and then to 4. -- For small tables it's better to extend them by a factor of 4 times, not 2, to make rehashing cost smaller for most hashtables, of cost of little higher memory consumption. -- For large tables it's better to have other load factor, closer to 1, while for small tables it's better to use load factor closer to 0.5. - APC was patched to take changes in Bucket structure into account. How was it tested? It was tested with make test, where one more (comparing to original sources) test fails, but it's most probably because http://bugs.php.net/bug.php?id=48858 - IMO test is badly constructed (is too simple) and any change of hashing function makes it fail. Also it was tested on our testing environment and production servers against30mln requests to our site, with 120requests/s at peak on Xeon @ 2.50GHz with 8GB RAM running Debian Linux. What is the gain? After tests CPU usage dropped by about 4% -6%. Memory footprint goes up just by few percent. What can be done in future? - Make new constants configurable by php.ini. - Test if changing arEmpty from byte-array to bit-array helps on performance. - Tweak default constants' values using some real-live benchmarks. - Prove (or modify
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
Hi! But I strongly believe in a threaded base solution for windows. That's the only way to get anywhere close to the performance we can see on other platforms (read: posix). My experience is that performance differnces between Windows and Linux has very little to do with server model, but much more to do with OS APIs (esp. filesystem, but not only). Also, threading PHP is generally slower than non-threading, so I don't see how threaded-base solution helps you there. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On Mon, Jan 31, 2011 at 11:33 PM, Stas Malyshev smalys...@sugarcrm.com wrote: But I strongly believe in a threaded base solution for windows. That's the only way to get anywhere close to the performance we can see on other platforms (read: posix). My experience is that performance differnces between Windows and Linux has very little to do with server model, but much more to do with OS APIs (esp. filesystem, but not only). Also, threading PHP is generally slower than non-threading, so I don't see how threaded-base solution helps you there. Well, let say we don't have the same experiences. And the threaded model in php is not that good anyway (TLS will help here). I did not say a threaded model can be the perfect solution but it is the way to go. The filesystem issues are mostly due to what we do in TS mode, way too much pointless operations, even if the real cache helps a little bit here (take this comment with a bit of salt: as in delta with the cache between TS and NTS). However, thinking that you can get anything close to what we have on unix using processes is a sweet dream, which will become a nightmare once you realized that past the little usual tricks, nothing will help you to go further (and we are there already). Any windows developers know that windows is not designed to perform well using processes. No real surprise either that almost all apps able to compare with their unix equivalent uses threads (only or in critical parts). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
Hi Pierre: On Mon, Jan 31, 2011 at 08:43:40PM +0100, Pierre Joye wrote: It does not matter what is the latest VC version. What matters is that VC6 is a dead cow and we won't support it anymore, even for the current stable, 5.3. And to be honest I don't really care about Apache.org's users (as in sticking to VC6) as they have a solution already, apachelounge.com. That's totally fine. The policy needs to explicitly explained on http://windows.php.net/. It should say that VC6 is no longer supported. It should also say something to the effect that people wanting to run PHP under Apache should download a VC9 version of PHP from here and then go to apachelounge for a VC9 version of Apache. The only reason I brought up the VC6 issue here is because of what winows.php.net currently says. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] implicit reference
Am 31.01.2011 21:08, schrieb Mathias Grimm: the constraint is that all need to run on php4.3.6 and 5.3 this need does not exist since php4 died a long time ago and now it's really time that some lazy people wake up everybody who has running php4 on prodcution servers has to be fired - remember php5.2 support is even ending and of course such stupid admins are tey one their servers get hacked and used for spambots and other nice things the world do not need signature.asc Description: OpenPGP digital signature
