# phpng: Refactored PHP Engine with Big Performance Improvement - Thread: https://externals.io/message/73888 - Original archive: https://news-web.php.net/php.internals/73888 - Started by Dmitry Stogov on 2014-05-05T13:07:44+00:00 - Messages: 115 - Page 1 of 5: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/73888.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #73888 — Dmitry Stogov — 2014-05-05T13:07:44+00:00 URL: https://externals.io/message/73888#73888 For people who know me it's not a secret that PHP performance is my main responsibility and passion at Zend. Actually, starting from PHP 5.0 we already made 6 times speedup on synthetic benchmarks and about 2 times speedup on real-life applications. We endlessly made improvements in PHP engine and OPCache. However, by PHP 5.5 release we weren’t be able to make any serious progress, and among other things started to experiment with memory managers, JIT technologies and other potential ideas. I spent a significant amount of time experimenting with JIT, and even created a PoC of transparent LLVM based JIT compiler embedded into OPCache. The results on bench.php was just amazing – (0.219 seconds against 2.175 – *10 times speedup of PHP 5.5*), but on real-life apps we got just few percent speedup. This made us look much deeper into some of the runtime characteristics and what was truly the bottleneck to making more substantial progress. It was clear the VM is already highly optimized, but works with data structures that require endless memory allocation, deallocation and reference counting. Typical real-life PHP application spends about 20% of the CPU time in memory manager, 10% doing hash tables operations, 30% in internal functions and only 30% in VM. Of course, we tried to JIT only VM code and in most cases it had to perform the same memory allocations. So we decided to change focus and work on the big bottlenecks. The idea was to change our data types to minimize heap allocations. This was a very difficult decision because we had to start with a huge refactoring, and we had no idea whether it’s going to have any impact or not. Now I'm glad to present you a result of our recent four month work. It's a refactoring of the PHP engine that significantly improves performance, memory usage and builds a foundation for a lot more future performance improvements incl. JIT. I'll avoid technical details (more details will be published at *http://wiki.php.net/phpng *), but in few words - we changed the basement trying to keep most of the building unchanged. Right now the new engine already makes *10-30% speedup of php*not only on benchmarks but on real-life applications as well! *Some benchmarks we ran so far:* Wordpress 3.6 – 20.0% gain (253 vs 211 req/sec) Drupal 6.1 – 11.7% gain (1770 vs 1585 req/sec Qdig – 15.3% gain (555 vs 482 req/sec) ZF test app – 30.5% gain (217 vs 166 req/sec) On some apps we show better results than other PHP implementations. It will be great if others here could test this on their apps and compare to their existing PHP version to get additional results. The re-factoring is not finished yet as the focus was to first test whether this effort would deliver results. Not all extensions are supported, some tests are failing, and we also have more ideas for additional improvement. But we feel, we’ve proven enough out to open it up for review, feedback and assistance, and wanted to involve the community as soon as we managed to get on a promising direction. There’s more work to do in finishing support of all extensions and continue to make some additional engine improvements. Please try the refactored PHP engine and provide feedback re: performance, memory usage and any issues that come up. You may find it in *phpng* branch at *php.net *. Some instructions may be found at *http://wiki.php.net/phpng *. As mentioned, there are some missing extensions so not everything will run. I would like to say many thanks to Xinchen and Nikita who made significant part of presented work. I think that this engine can make the new major version of PHP we’re talking about a lot more interesting. Thanks. Dmitry. --- ## #73889 — Sebastian Bergmann — 2014-05-05T13:49:52+00:00 URL: https://externals.io/message/73888#73889 · In reply to: #73888 Am 05.05.2014 15:07, schrieb Dmitry Stogov: > But we feel, we’ve proven enough out to open it up for review, feedback > and assistance, and wanted to involve the community as soon as we managed > to get on a promising direction. There’s more work to do in finishing > support of all extensions and continue to make some additional engine > improvements. Tried running PHPUnit 4.1's test suite with phpng: https://gist.github.com/sebastianbergmann/ad46f8e4e923578a72d5 --- ## #73890 — Dmitry Stogov — 2014-05-05T13:56:05+00:00 URL: https://externals.io/message/73888#73890 · In reply to: #73889 It looks like a bug in GC. We will care about it in some point. Thanks. Dmitry. On Mon, May 5, 2014 at 5:49 PM, Sebastian Bergmann wrote: > Am 05.05.2014 15:07, schrieb Dmitry Stogov: > > […] > > Tried running PHPUnit 4.1's test suite with phpng: > https://gist.github.com/sebastianbergmann/ad46f8e4e923578a72d5 --- ## #73891 — Andrea Faulds — 2014-05-05T14:01:20+00:00 URL: https://externals.io/message/73888#73891 · In reply to: #73888 This seems like something that would be a big feature for PHP 6. How much backwards-compatibility does it break? -- Andrea Faulds http://ajf.me/ --- ## #73892 — Kevin Ingwersen — 2014-05-05T14:07:18+00:00 URL: https://externals.io/message/73888#73892 · In reply to: #73888 Hey! This sounds like an amazing bit of updatng! :) I am very much looking forward to the new release of PHP. But, there is soemthing I do not understand. I know that Zend is the current underlying VM, and further, this is not actual work by the PHP team…am I right? Further, will phpng replace the vm, or even more parts? Will it still need components like TSRM? I am just asking, as I have been working with PHP within embedded aplications for a while now (currently working on porting autoconf to cDetect). If parts of the source tree structure changed, I would need to refactor the building part as well. Also, I am currently running a rather small but active community. To test phpng, I was thinking about silently injecting it thru the cgi script, to see how the performance owuld change. Does phpng have any effects on currently existing extensions (PDO, memcached)? Kind regards, Ingwie! Am 05.05.2014 um 15:07 schrieb Dmitry Stogov : > For people who know me it's not a secret that PHP performance is my main > responsibility and passion at Zend. Actually, starting from PHP 5.0 we > already made 6 times speedup on synthetic benchmarks and about 2 times > speedup on real-life applications. We endlessly made improvements in PHP > engine and OPCache. However, by PHP 5.5 release we weren’t be able to make > any serious progress, and among other things started to experiment with > memory managers, JIT technologies and other potential ideas. > > I spent a significant amount of time experimenting with JIT, and even > created a PoC of transparent LLVM based JIT compiler embedded into OPCache. > The results on bench.php was just amazing – (0.219 seconds against 2.175 – *10 > times speedup of PHP 5.5*), but on real-life apps we got just few percent > speedup. This made us look much deeper into some of the runtime > characteristics and what was truly the bottleneck to making more > substantial progress. It was clear the VM is already highly optimized, but > works with data structures that require endless memory allocation, > deallocation and reference counting. Typical real-life PHP application > spends about 20% of the CPU time in memory manager, 10% doing hash tables > operations, 30% in internal functions and only 30% in VM. Of course, we > tried to JIT only VM code and in most cases it had to perform the same > memory allocations. So we decided to change focus and work on the big > bottlenecks. The idea was to change our data types to minimize heap > allocations. This was a very difficult decision because we had to start > with a huge refactoring, and we had no idea whether it’s going to have any > impact or not. > > Now I'm glad to present you a result of our recent four month work. It's a > refactoring of the PHP engine that significantly improves performance, > memory usage and builds a foundation for a lot more future performance > improvements incl. JIT. I'll avoid technical details (more details will be > published at *http://wiki.php.net/phpng *), but > in few words - we changed the basement trying to keep most of the building > unchanged. Right now the new engine already makes *10-30% speedup of > php*not only on benchmarks but on real-life applications as well! > > *Some benchmarks we ran so far:* > > Wordpress 3.6 – 20.0% gain (253 vs 211 req/sec) > > Drupal 6.1 – 11.7% gain (1770 vs 1585 req/sec > > Qdig – 15.3% gain (555 vs 482 req/sec) > > ZF test app – 30.5% gain (217 vs 166 req/sec) > > On some apps we show better results than other PHP implementations. It will > be great if others here could test this on their apps and compare to their > existing PHP version to get additional results. > > The re-factoring is not finished yet as the focus was to first test whether > this effort would deliver results. Not all extensions are supported, some > tests are failing, and we also have more ideas for additional improvement. > > But we feel, we’ve proven enough out to open it up for review, feedback > and assistance, and wanted to involve the community as soon as we managed > to get on a promising direction. There’s more work to do in finishing > support of all extensions and continue to make some additional engine > improvements. > > Please try the refactored PHP engine and provide feedback re: performance, > memory usage and any issues that come up. You may find it in *phpng* branch > at *php.net *. Some instructions may be found at > *http://wiki.php.net/phpng > *. As mentioned, there are some missing > extensions so not everything will run. > > I would like to say many thanks to Xinchen and Nikita who made significant > part of presented work. > > I think that this engine can make the new major version of PHP we’re > talking about a lot more interesting. > > Thanks. Dmitry. --- ## #73893 — Dmitry Stogov — 2014-05-05T14:15:12+00:00 URL: https://externals.io/message/73888#73893 · In reply to: #73891 I would say it must be 100% compatible at the end, may be with exception for very rare and unclear cases that worked just because of existing implementation. (e.g. mixing foreach and `next()` on the same array). Thanks. Dmitry. > This seems like something that would be a big feature for PHP 6. How much > backwards-compatibility does it break? > > -- > Andrea Faulds > http://ajf.me/ --- ## #73894 — Andrea Faulds — 2014-05-05T14:16:50+00:00 URL: https://externals.io/message/73888#73894 · In reply to: #73893 > I would say it must be 100% compatible at the end, may be with exception for very rare and unclear cases that worked just because of existing implementation. (e.g. mixing foreach and `next()` on the same array). Of course it’s compatible with user land, what I meant to ask was how compatible is the ABI? Would this require a lot of changes to extensions and such? -- Andrea Faulds http://ajf.me/ --- ## #73895 — Andi Gutmans — 2014-05-05T14:24:53+00:00 URL: https://externals.io/message/73888#73895 · In reply to: #73892 Hi Kevin, The Zend Engine for many years now has been an integral part of the PHP source tree and enjoys contributors from all over the community (not just Zend). This refactoring exercise doesn’t change any of that and as Dmitry mentioned, is really a refactoring of the Zend Engine vs. a new thing. This started as experimental work and once we figured it was a great, viable direction to head in we decided to share it. It does have implications for PHP extensions because we made changes to the datatype structures, etc. but it’s been relatively straightforward to update the various extensions to conform to the refactored structures. The benefits do seem to be massive (exceeding our initial expectations). Memory usage is *significantly* down, overall performance impact on real-world apps is significant and with these changes it’s opened up a lot of additional opportunities for further optimization down the road as we are not bottlenecked by our data structures. Andi > Hey! > > This sounds like an amazing bit of updatng! :) I am very much looking forward to the new release of PHP. But, there is soemthing I do not understand. > > I know that Zend is the current underlying VM, and further, this is not actual work by the PHP team…am I right? > Further, will phpng replace the vm, or even more parts? Will it still need components like TSRM? > > I am just asking, as I have been working with PHP within embedded aplications for a while now (currently working on porting autoconf to cDetect). If parts of the source tree structure changed, I would need to refactor the building part as well. > > Also, I am currently running a rather small but active community. To test phpng, I was thinking about silently injecting it thru the cgi script, to see how the performance owuld change. Does phpng have any effects on currently existing extensions (PDO, memcached)? > > Kind regards, Ingwie! > Am 05.05.2014 um 15:07 schrieb Dmitry Stogov : > > > […] --- ## #73896 — Dmitry Stogov — 2014-05-05T14:26:06+00:00 URL: https://externals.io/message/73888#73896 · In reply to: #73892 On Mon, May 5, 2014 at 6:07 PM, Kevin Ingwersen wrote: > Hey! > > This sounds like an amazing bit of updatng! :) I am very much looking > forward to the new release of PHP. But, there is soemthing I do not > understand. > > I know that Zend is the current underlying VM, and further, this is not > actual work by the PHP team…am I right? > Further, will phpng replace the vm, or even more parts? I wouldn't talk about replacement. It's the same PHP with the evoluted Zend Engine (even the less significant change than moving from PHP-4 to PHP-5). > Will it still need components like TSRM? > yes. > I am just asking, as I have been working with PHP within embedded > aplications for a while now (currently working on porting autoconf to > cDetect). If parts of the source tree structure changed, I would need to > refactor the building part as well. > > Also, I am currently running a rather small but active community. To test > phpng, I was thinking about silently injecting it thru the cgi script, to > see how the performance owuld change. Does phpng have any effects on > currently existing extensions (PDO, memcached)? > yes. All the extensions need to be "ported" to support phpng. Thanks. Dmitry. --- ## #73897 — Andi Gutmans — 2014-05-05T14:26:48+00:00 URL: https://externals.io/message/73888#73897 · In reply to: #73894 Yes it does require changes in the extensions. I must say we’ve been able to hammer through them pretty quickly but it does require change due to the refactoring of the data types. It’s a refactoring exercise though not a rewrite. So relatively speaking not too painful and I think we’ve already worked through many of them so there are a lot of examples. Andi > > > > > […] > > Of course it’s compatible with user land, what I meant to ask was how compatible is the ABI? Would this require a lot of changes to extensions and such? > > -- > Andrea Faulds > http://ajf.me/ --- ## #73898 — Laruence — 2014-05-05T14:28:44+00:00 URL: https://externals.io/message/73888#73898 · In reply to: #73894 Hey: > > > > > […] > > Of course it’s compatible with user land, what I meant to ask was how compatible is the ABI? Would this require a lot of changes to extensions and such? Not very much changes. the most significant changes are zend_hash_* APIs. but it's not very difficult to port a old ext into php-ng form thanks > > -- > Andrea Faulds > http://ajf.me/ > > > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #73899 — Dmitry Stogov — 2014-05-05T14:30:05+00:00 URL: https://externals.io/message/73888#73899 · In reply to: #73894 yes. all the extensions will have to be changed. In some cases it may be difficult, but usually not too difficult. For example today Xinchen added support for 3 or 5 new extensions. Thanks. Dmitry. > > > > I would say it must be 100% compatible at the end, may be with exception > for very rare and unclear cases that worked just because of existing > implementation. (e.g. mixing foreach and `next()` on the same array). > > > Of course it’s compatible with user land, what I meant to ask was how > compatible is the ABI? Would this require a lot of changes to extensions > and such? > > -- > Andrea Faulds > http://ajf.me/ --- ## #73900 — Andrea Faulds — 2014-05-05T14:30:47+00:00 URL: https://externals.io/message/73888#73900 · In reply to: #73897 Hmm. This is unrelated, but while you’re busy refactoring PHP, could you comment and document the bits you refactor a bit more? More documentation can only be a good thing, and it’s something Zend is sorely lacking. -- Andrea Faulds http://ajf.me/ --- ## #73901 — Dmitry Stogov — 2014-05-05T14:31:52+00:00 URL: https://externals.io/message/73888#73901 · In reply to: #73900 I'm doing it right now: https://wiki.php.net/phpng-int Thanks. Dmitry. > Hmm. This is unrelated, but while you’re busy refactoring PHP, could you > comment and document the bits you refactor a bit more? More documentation > can only be a good thing, and it’s something Zend is sorely lacking. > > -- > Andrea Faulds > http://ajf.me/ --- ## #73902 — Andi Gutmans — 2014-05-05T14:33:51+00:00 URL: https://externals.io/message/73888#73902 · In reply to: #73900 Yep agree. We started and definitely will need to do mode. Sent from my iPhone > > > Hmm. This is unrelated, but while you’re busy refactoring PHP, could you comment and document the bits you refactor a bit more? More documentation can only be a good thing, and it’s something Zend is sorely lacking. > > -- > Andrea Faulds > http://ajf.me/ --- ## #73903 — Andrea Faulds — 2014-05-05T14:34:24+00:00 URL: https://externals.io/message/73888#73903 · In reply to: #73901 > I'm doing it right now: https://wiki.php.net/phpng-int That’s great to see, thanks! -- Andrea Faulds http://ajf.me/ --- ## #73904 — Kevin Ingwersen — 2014-05-05T14:42:04+00:00 URL: https://externals.io/message/73888#73904 · In reply to: #73902 Am 05.05.2014 um 16:33 schrieb Andi Gutmans : > Yep agree. We started and definitely will need to do mode. > > Sent from my iPhone Mode? I think auto-correct likes you today =p Thats awesome, thanks for the replies. Hopefully the people at PHP-CPP will update their API as well to suit the updates, so that these things will continue to work as before. One thing, as you are on documenting: Documenting class usage from the C side (modifying properties etc) would be good to be documented a little bit more. Last time I looked into it, the object accessing API part was poorly documented. Going to do testing with phpng now and send results later. I will silently inject it into my currently running site, seeing how the performance will change. Kind regards, Ingwie. > > […] --- ## #73907 — johannes@schlueters.de — 2014-05-05T15:26:21+00:00 URL: https://externals.io/message/73888#73907 · In reply to: #73901 Hi, > I'm doing it right now: https://wiki.php.net/phpng-int I haven't looked deeply into it, but a thing I wondered about old zvals already: CELL Format (zval) +----------------------------------------------------------------------------------+ | VALUE (64-bit) | +--------------------------+-------------+-------------+-------------+-------------+ | UNUSED (32-bit) | UNUSED | const_flags | type_flags | TYPE | +--------------------------+-------------+-------------+-------------+-------------+ 63 32 31 24 23 16 15 8 7 0 Have you tried movin the TYPE to the einning of the structure? - I assume checking/setting the type is the most common operation. By moving it upfront the address of the type equals the address of the zval, thus the CPU should be ale to access it without offset, might improve pipeline throughput. I haven't measured that, but miht be interesting while already chaning this. johannes --- ## #73908 — php@thekid.de — 2014-05-05T17:28:01+00:00 URL: https://externals.io/message/73888#73908 · In reply to: #73888 Hi, > Now I'm glad to present you a result of our recent four month work. It's a > refactoring of the PHP engine that significantly improves performance, > memory usage and builds a foundation for a lot more future performance > improvements incl. JIT. Wow, some great work! I do see a couple of failures running the XP Framework’s test suite (I’ll have a look into these and try to figure out what’s going on), but comparing these that *are* working, I can see the following: PHP 5.4 OK: 1019/1042 run (23 skipped), 1019 succeeded, 0 failed Memory used: 13877.78 kB (14830.66 kB peak) Time taken: 0.692 seconds PHP 5.5 OK: 1019/1042 run (23 skipped), 1019 succeeded, 0 failed Memory used: 13942.30 kB (14900.96 kB peak) Time taken: 0.583 seconds phpng OK: 1017/1042 run (25 skipped), 1017 succeeded, 0 failed Memory used: 10790.42 kB (11754.17 kB peak) Time taken: 0.385 seconds - Timm --- ## #73909 — Dmitry Stogov — 2014-05-05T17:59:25+00:00 URL: https://externals.io/message/73888#73909 static HTML is served by web server and it's irrelevant to PHP performance. Thanks. Dmitry. On Mon, May 5, 2014 at 6:59 PM, Thomas Hruska wrote: > > > > […] > What's the comparison to serving static HTML through PHP (no PHP tags) on > the same setup? > > -- > Thomas Hruska > CubicleSoft President > > I've got great, time saving software that you will find useful. > > http://cubiclesoft.com/ --- ## #73910 — Dmitry Stogov — 2014-05-05T18:01:29+00:00 URL: https://externals.io/message/73888#73910 · In reply to: #73907 The improvement are made with JIT in mind. In the future, in many places we might predict the type and don't check it at all. Thanks. Dmitry. On Mon, May 5, 2014 at 7:26 PM, Johannes Schlüter wrote: > Hi, > > > > […] > > I haven't looked deeply into it, but a thing I wondered about old zvals > already: > > CELL Format (zval) > > > +----------------------------------------------------------------------------------+ > | VALUE (64-bit) > | > > +--------------------------+-------------+-------------+-------------+-------------+ > | UNUSED (32-bit) | UNUSED | const_flags | type_flags | > TYPE | > > +--------------------------+-------------+-------------+-------------+-------------+ > 63 32 31 24 23 16 15 8 7 > 0 > > Have you tried movin the TYPE to the einning of the structure? - I > assume checking/setting the type is the most common operation. By moving > it upfront the address of the type equals the address of the zval, thus > the CPU should be ale to access it without offset, might improve > pipeline throughput. > > I haven't measured that, but miht be interesting while already chaning > this. > > johannes --- ## #73911 — Dmitry Stogov — 2014-05-05T18:16:47+00:00 URL: https://externals.io/message/73888#73911 · In reply to: #73908 Thanks for results! 34% speed improvement and 22% memory consumption improvement in comparison to PHP 5.5 I'm always getting better results when bench against competitors myself :) So the third party benchmarks and comparisons really helps. phpng is still far away from production quality yet. It actually served the first wordpress request just a month ago. I hope we will able to catch most of the bugs soon. Thanks. Dmitry. > Hi, > > > […] > a > > […] > > Wow, some great work! > > I do see a couple of failures running the XP Framework’s test suite (I’ll > have a look into these and try to figure out what’s going on), but > comparing these that *are* working, I can see the following: > > PHP 5.4 > OK: 1019/1042 run (23 skipped), 1019 succeeded, 0 failed > Memory used: 13877.78 kB (14830.66 kB peak) > Time taken: 0.692 seconds > > PHP 5.5 > OK: 1019/1042 run (23 skipped), 1019 succeeded, 0 failed > Memory used: 13942.30 kB (14900.96 kB peak) > Time taken: 0.583 seconds > > phpng > OK: 1017/1042 run (25 skipped), 1017 succeeded, 0 failed > Memory used: 10790.42 kB (11754.17 kB peak) > Time taken: 0.385 seconds > > - Timm --- ## #73912 — Bob Weinand — 2014-05-05T19:08:19+00:00 URL: https://externals.io/message/73888#73912 · In reply to: #73901 Am 5.5.2014 um 16:31 schrieb Dmitry Stogov : > I'm doing it right now: https://wiki.php.net/phpng-int > > Thanks. Dmitry. > > > > > > […] Nice work! Just wondering why http://git.php.net/?p=php-src.git;a=commitdiff;h=f614fc68984b2d7fce3f275b8106955b5d910472 was reverted in phpng? Is there any real reason to still use IS_CONSTANT_ARRAY? The AST variant is much nicer, fixes a bug and removes the IS_CONSTANT_INDEX hack. Bob --- ## #73913 — Timm Friebe — 2014-05-05T19:31:27+00:00 URL: https://externals.io/message/73888#73913 · In reply to: #73888 Hi again, > ... It's been brought to my attention that in my previous comparison, there were also two skipped tests I'd overlooked, I've commented them so we're actually comparing apples with apples. Also, I got a couple more tests working, so here we go: 5.5 OK: 2987/3013 run (26 skipped), 2987 succeeded, 0 failed Memory used: 37065.45 kB (37350.91 kB peak) Time taken: 2.133 seconds phpng OK: 2987/3013 run (26 skipped), 2987 succeeded, 0 failed Memory used: 29315.42 kB (29583.73 kB peak) Time taken: 1.603 seconds > (I’ll have a look into these and try to figure out what’s going on) Here's my summary of why there are failing tests (all of these work fine with 5.4, 5.6-beta2, 5.7-dev-master). I've tried fixing them but haven't succeeded, but I thought I'd tell you anyways. 1) Process control functions ============================ `proc_close()` seems to always return exit code 1 regardless of the actual exit code: $ ./sapi/cli/php -r '$p= proc_open("ls -al buildconf", [0 => ["pipe", "r"], 1 => ["pipe", "w"], 2 => ["pipe", "w"]], $pipes); var_dump(fread($pipes[1], 1024)); foreach ($pipes as $pipe) { fclose($pipe); } var_dump(proc_close($p));' string(54) "-rwxr-xr-x 1 friebe friebe 772 Apr 18 16:21 buildconf " int(1) (should be: 0) $ ./sapi/cli/php -r '$p= proc_open("ls -ü", [0 => ["pipe", "r"], 1 => ["pipe", "w"], 2 => ["pipe", "w"]], $pipes); var_dump(fread($pipes[1], 1024)); foreach ($pipes as $pipe) { fclose($pipe); } var_dump(proc_close($p));' string(0) "" int(1) (should be: 2) It works fine in both situations if I don't explicitely `fclose()` all the pipes. 2) Fatal error with DateTime ============================ DateTime::date_timezone_set() must be derived from Date::date_timezone_set in Unknown on line 0 DateTimeInterface::date_format() must be derived from Date::date_format in Unknown on line 0 Unfortunately I can't exactly produce a small script to reproduce, but the `Date` class mentioned above basically does this: class Date extends Object {   public function __construct($in) {     $this->value= date_create($in, timezone_open(...));   } } These errors are both produced by zend_parse_method_parameters(), where this_ptr points to the class `Date` and not to `DateTime`. I've only seen them with the date extension, nowhere else so far. Maybe that helps you. 3) Fatal error: Can only throw objects ====================================== References cause this. The ensure() function prevents uninitialized variable warnings: $ ./sapi/cli/php -r 'function ensure(&$e) { if ($e) return true; $e= null; return false; } $e= new Exception(""); if (ensure($e)) { throw $e; }' Fatal error: Can only throw objects in Command line code on line 1 Expected outcome: PHP Fatal error:  Uncaught exception 'Exception' in Command line code:1 # ... Adding a var_dump($e) right before the `throw` will actually dump the exception, so I guess this some refcount issue. -Timm --- ## #73914 — Dmitry Stogov — 2014-05-05T19:32:58+00:00 URL: https://externals.io/message/73888#73914 · In reply to: #73912 Hi Bob, Actually, our patches were orthogonal, resolving the same hack in different ways. Sorry, I had a lot of work, and missed your patch when you committed it. Then I just wasn't able to merge them in reasonable time. We will need to discuss it in more details and then reimplement on top of phpng or revert in master. The thing I don't like in the patch, that you converted every IS_CONSTANT_ARRAY into IS_CONSTANT_AST. With this approach all the constant arrays have to be evaluated at run-time. However, I think about optimization when we won't copy constant arrays (without symbolic constants) from shared memory at all. I might be wrong, or misunderstand something in your patch, so we'll definitely need to talk, but now I would prefer to close the known problems first. Let's speak on next week. Thanks. Dmitry. > Am 5.5.2014 um 16:31 schrieb Dmitry Stogov : > > I'm doing it right now: https://wiki.php.net/phpng-int > > Thanks. Dmitry. > > > > > Hmm. This is unrelated, but while you’re busy refactoring PHP, could you > comment and document the bits you refactor a bit more? More documentation > can only be a good thing, and it’s something Zend is sorely lacking. > > -- > Andrea Faulds > http://ajf.me/ > > > Nice work! > > Just wondering why > http://git.php.net/?p=php-src.git;a=commitdiff;h=f614fc68984b2d7fce3f275b8106955b5d910472was reverted in phpng? > > Is there any real reason to still use IS_CONSTANT_ARRAY? The AST variant > is much nicer, fixes a bug and removes the IS_CONSTANT_INDEX hack. > > Bob --- Next page: https://externals.io/message/73888.md?page=2