# Reporting bugs for phpng - Thread: https://externals.io/message/76119 - Original archive: https://news-web.php.net/php.internals/76119 - Started by Pascal Chevrel on 2014-07-25T13:14:06+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #76119 — Pascal Chevrel — 2014-07-25T13:14:06+00:00 URL: https://externals.io/message/76119#76119 Hi, I tried the .deb package for phpng that Zend provides since yesterday (thanks for that!) and I hit a memory consumption issue with the first of my scripts I tried: PHPNG: Memory peak: 62914560 (55.97MB) Elapsed time (s): 0.3383 PHP 5.5: Memory peak: 1835008 (1.64MB) Elapsed time (s): 0.0717 How/where can I make a bug report about it? Is https://bugs.php.net/ ok for PHPNG bugs? Thanks Pascal --- ## #76155 — Laruence — 2014-07-26T02:42:20+00:00 URL: https://externals.io/message/76119#76155 · In reply to: #76119 Hey: > Hi, > > I tried the .deb package for phpng that Zend provides since yesterday > (thanks for that!) and I hit a memory consumption issue with the first of my > scripts I tried: > > PHPNG: > Memory peak: 62914560 (55.97MB) > Elapsed time (s): 0.3383 > > PHP 5.5: > Memory peak: 1835008 (1.64MB) > Elapsed time (s): 0.0717 > > How/where can I make a bug report about it? Is https://bugs.php.net/ ok for > PHPNG bugs? PHPNG is not listed in bugs.php.net yet. but as it's a branch of PHP , I think it's okey to report it there, and note it's PHPNG in the comment. for now. thanks > > Thanks > > Pascal > > -- > > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #76290 — Matteo Beccati — 2014-07-31T13:31:27+00:00 URL: https://externals.io/message/76119#76290 · In reply to: #76155 > PHPNG is not listed in bugs.php.net yet. but as it's a branch of PHP > , I think it's okey to report it there, and note it's PHPNG in the > comment. for now. wouldn't it be fairly easy to create a new entry in the version dropdown? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #76291 — Laruence — 2014-07-31T14:23:33+00:00 URL: https://externals.io/message/76119#76291 Hey: > Le 26/07/2014 04:42, Laruence a écrit : > > > […] > > > Hi, > > I opened this bug: > https://bugs.php.net/bug.php?id=67725 > > I put a testcase triggering the memory leak in a github repo referenced in > the bug. I am afraid this is not a bug. it's due to our new immutable array implementation. all these langs map array are constant array, such it will be treat as immutable array, which means it will not be released untill the request shutdown. (which will bring significant performance improvement for saving array construct/destruct while use with opcache) I suggest you to increase the memory_limit as a workaround .. Anyway, Dmitry, what do you think? maybe something like interned_string_size? thanks > > Regards > > > Pascal > > > -- > > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #76299 — Nikita Popov — 2014-07-31T20:18:09+00:00 URL: https://externals.io/message/76119#76299 · In reply to: #76291 > Hey: > > I am afraid this is not a bug. > > it's due to our new immutable array implementation. > > all these langs map array are constant array, such it will be treat as > immutable array, which means it will not be released untill the > request shutdown. (which will bring significant performance > improvement for saving array construct/destruct while use with > opcache) > > I suggest you to increase the memory_limit as a workaround .. > > Anyway, Dmitry, what do you think? maybe something like > interned_string_size? > Another idea: We could refrain from creating immutable arrays for top-level scripts (only do it in functions, methods etc). As function op arrays never get dtor'd there would be no problem there. Nikita --- ## #76300 — Andrea Faulds — 2014-07-31T20:22:02+00:00 URL: https://externals.io/message/76119#76300 > The problem is that the more arrays I load, the more memory PHPNG consumes while current versions of PHP have that value mostly stable. I have with PHPNG a scalability issue I don't have with regular PHP. If tomorrow I increase the number of languages I support in my app from 70 to 200 (which is my long term goal btw), I would probably need to set memory_limit to 700MB which seems honestly crazy when PHP 5.x needs 8MB for the same script to run at the same speed. As an end user, I think it's a bug not a feature, I hope you understand my point of view :). This isn’t so much a response to Pascal, more a question for the rest of you. My apologies if I’m misunderstanding this internally. As the array is in opcache, we can just use it directly without copying, right? In which case, shouldn’t Pascal’s issue not be happening, or is Pascal not using opcache? Or, are we copying each time we run the script? In which case, why aren’t we using opcache’s copy? -- Andrea Faulds http://ajf.me/ --- ## #76310 — Laruence — 2014-08-01T08:21:00+00:00 URL: https://externals.io/message/76119#76310 > Le 31/07/2014 16:23, Laruence a écrit : > > > […] > > Hi, > > The problem is that the more arrays I load, the more memory PHPNG consumes > while current versions of PHP have that value mostly stable. I have with > PHPNG a scalability issue I don't have with regular PHP. If tomorrow I > increase the number of languages I support in my app from 70 to 200 (which > is my long term goal btw), I would probably need to set memory_limit to > 700MB which seems honestly crazy when PHP 5.x needs 8MB for the same script > to run at the same speed. As an end user, I think it's a bug not a feature, > I hope you understand my point of view :). I understand your point, and the problem, but the thing here is, do you really needs loads all langs map arrays in a single request(as I understand you only need one per request, right?) > > Also, people on shared hosting can't change the memory_limit value, it > doesn't sound like a change that is good for PHP in shared hosting > environment which is a large part of PHP success. > > You mention that it is beneficial when OPCache is activated, but it isn't > activated by default, so the theoretical gain would only work for people > that can activate it, right? Or does it mean that OPCache would be activated > by default in PHP 7? I will suggest to enable it by default in NG. > > Is there no way to release the memory programmatically before the request > ends? Shouldn't explicitely using unset() on the array at the end of each > iteration indicate to the engine that I don't just want to destroy the array > reference but also get the memory back? That sounds like a very significant > change in how PHP behaves today with arrays, doesn't it? PHPNG is promoted > as a big speed optimization that wouldn't impact userland code, well, in my > case it does and very significantly if parts of my app crash or use 20 or 30 > times more memory than before for a 5% speed gain, it's not a win. If there > is a way to force PHP to unload that data from memory and basically behave > like PHP 5.x it could at least be in PHP 7 upgrade release notes for people > like me that build stuff on today's PHP strengths. hmm, I will definitely ask dmitry 's idea.. thanks > > Thanks, > > > Pascal > > -- > > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #76338 — Dmitry Stogov — 2014-08-04T16:23:30+00:00 URL: https://externals.io/message/76119#76338 hi Pascal, Laruence is right - immutable arrays are not destroyed until the end of request and this causes a problem in your case. I've committed a partial fix that destroys unnecessary copies when script is cached by OPCache, but it doesn't work without opcache or when it doesn't have enough shared memory. Disabling immutable arrays for top-level code looks as a too pessimistic decision. Most apps have their configuration arrays in top-level code and only few might be affected by this problem... I think, we may introduce new pragma that might enable/disable immutable array creation during compilation. So applications that use a lot of big arrays may modify the default behaviour for some files. e.g. 'off'); $a = array(...); ?> Thoughts? Thanks. Dmitry. On Fri, Aug 1, 2014 at 12:39 PM, Pascal Chevrel wrote: > Le 01/08/2014 10:21, Laruence a écrit : > > On Fri, Aug 1, 2014 at 12:34 AM, Pascal Chevrel > > […] > Hi, > > No, this testcase is a cut down version of the real code I wrote to make > it easier to detect the problem I was facing, the real code is part of a > specific view that is also an API allowing to consult all translations > available for a specific string ID in our code base, examples: > http://transvision.mozfr.org/api/v1/entity/central/?id= > browser/chrome/browser/browser.dtd:bookmarkThisPageCmd.label > > http://transvision.mozfr.org/string/?entity=browser/chrome/ > browser/browser.dtd:bookmarkThisPageCmd.label&repo=central > > Cheers > > > Pascal --- ## #76339 — Pierre Joye — 2014-08-04T17:06:24+00:00 URL: https://externals.io/message/76119#76339 · In reply to: #76338 hi Dmitry, > hi Pascal, > > Laruence is right - immutable arrays are not destroyed until the end of > request and this causes a problem in your case. > > I've committed a partial fix that destroys unnecessary copies when script > is cached by OPCache, but it doesn't work without opcache or when it > doesn't have enough shared memory. > > Disabling immutable arrays for top-level code looks as a too pessimistic > decision. Most apps have their configuration arrays in top-level code and > only few might be affected by this problem... > > I think, we may introduce new pragma that might enable/disable immutable > array creation during compilation. > So applications that use a lot of big arrays may modify the default > behaviour for some files. > > e.g. > > declare(immutable_arrays=>'off'); > $a = array(...); > ?> > > Thoughts? As I agree that a solution has to be found, introducing pragma is definitively not something I like to see in PHP, options like that are way too low level and should not be exposed in userland. It will make PHP way too complex. Cheers, Pierre --- ## #76340 — Andrea Faulds — 2014-08-04T17:26:11+00:00 URL: https://externals.io/message/76119#76340 · In reply to: #76339 > As I agree that a solution has to be found, introducing pragma is > definitively not something I like to see in PHP, options like that are > way too low level and should not be exposed in userland. It will make > PHP way too complex. Perhaps I’m being technically ignorant here, but would it not be possible to disable immutable arrays when opcache is not in use? -- Andrea Faulds http://ajf.me/ --- ## #76341 — Dmitry Stogov — 2014-08-04T17:44:57+00:00 URL: https://externals.io/message/76119#76341 · In reply to: #76340 We can disable immutable arrays when opcache not loaded or disabled. But it's going to be difficult to disable them when script can't fit into SHM, because at the moment of compilation (or optimization) we don't know the final required size. Thanks. Dmitry. > > > > > […] > > Perhaps I’m being technically ignorant here, but would it not be possible > to disable immutable arrays when opcache is not in use? > > -- > Andrea Faulds > http://ajf.me/ --- ## #76351 — Dmitry Stogov — 2014-08-05T11:41:25+00:00 URL: https://externals.io/message/76119#76351 · In reply to: #76341 Now it must be completely fixed in git. Thanks. Dmitry. > We can disable immutable arrays when opcache not loaded or disabled. > But it's going to be difficult to disable them when script can't fit into > SHM, because at the moment of compilation (or optimization) we don't know > the final required size. > > Thanks. Dmitry. > > > > > > […] --- ## #76354 — Ferenc Kovacs — 2014-08-05T13:35:24+00:00 URL: https://externals.io/message/76119#76354 On Tue, Aug 5, 2014 at 2:14 PM, Pascal Chevrel wrote: > Le 05/08/2014 14:01, Pascal Chevrel a écrit : > > Le 05/08/2014 13:41, Dmitry Stogov a écrit : > > […] > Actually, shouldn't 'php -i' expose somewhere the php-src revision that > was used for compiling to make QA easier? (PHP in general, not a PHPNG > specific question) > > > Regards > > Pascal > > -- > > > > compiling php from version control is for development purposes, so if somebody decides to ship binaries based on an untagged php version, it is his/her responsibility to provide a way for the end user to be able to figure out the exact version which was used for the build. the official php versions all use a separate version and even the http://snaps.php.net/ tarballs have a prise date in the filename to make it easier to tell which version was used as a basis (I think it would make sense to also add the git verion to the filename). I don't think that it would be a good idea to adjust our current build system to check if the build is done from git and patch the php version files on-the-fly so that the the resulting binary can tell which git version was used. -- Ferenc Kovács @Tyr43l - http://tyrael.hu