Edit report at http://bugs.php.net/bug.php?id=51155&edit=1
ID: 51155 Updated by: dmi...@php.net Reported by: flavius dot as at gmail dot com Summary: Unreasonable non-emalloc allocations of memory -Status: Assigned +Status: Closed Type: Bug Package: Scripting Engine problem Operating System: ArchLinux x86_64 PHP Version: 5.3.2 Assigned To: dmitry Block user comment: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2010-10-04 17:50:48] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=304031 Log: Bug #51155 (Unreasonable non-emalloc allocations of memory) ------------------------------------------------------------------------ [2010-04-25 06:55:26] col...@php.net This is not related to SPL nor to serialize. In fact, it's simply that your functions make PHP allocate a lot of memory on the side (not using emalloc). Try with memory_get_usage(true); you'll see that you hit already ~128M before even serializing, This is a bit smaller using a normal array, so it's not really related to SplFixedArray. ------------------------------------------------------------------------ [2010-03-27 14:45:00] flavius dot as at gmail dot com updated version ------------------------------------------------------------------------ [2010-03-04 15:10:04] flavius dot as at gmail dot com Ok, I've managed to compile and test with php5.3-201003041130, the bug is still there, but it seems to crash for higher values. for 20000 items, the peak is peak 21.71 mb before serialize, peak 45.59 mb after serialize. simple maths: it should need approximatively 5 mb for every 5000 items. The following test run for 25000 confirms my theory (roughly, +/- due to temporarily saving the return value, runtime memory, etc): before serialization: peak 26.98 mb after: peak 56.7 mb Ok, it's slightly higher than 5mb, after serialization is a small increase over the expected (which I presumed) 2*n linear growth. Now the final run. But first and foremost $ sapi/cli/php -i |grep memory memory_limit => 128M => 128M And the test run, for 30000 items: GENERATING DONE peak 32.24 mb --- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 28574231 bytes) The expected value was somewhere around (and I'll be generous) 80mb. But I suppose it still has that spark of exponential growth somewhere between 25000 and 30000 items. ------------------------------------------------------------------------ [2010-03-04 14:30:17] paj...@php.net That's unrelated to this bug, disable imap to test a new build. However, about this error, get a decent c-client and it will work (like less than 4-5 years old). ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51155 -- Edit this bug report at http://bugs.php.net/bug.php?id=51155&edit=1
