Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.0a1

Request #7563 Improve memory usage
Submitted: 2006-05-05 11:52 UTC
From: yunosh Assigned: ashnazg
Status: Wont fix Package: PhpDocumentor (version 1.3.0RC6)
PHP Version: 4.3.11 OS: FreeBSD 4.11-STABLE
Roadmaps: (Not assigned)    

 [2006-05-05 11:52 UTC] yunosh (Jan Schneider)
Description: ------------ When generating the API docs for Horde's framework module, we get the following error each time: php in malloc(): warning: recursive call FATAL: emalloc(): Unable to allocate 129 bytes All other modules work fine, and even the API docs seem to be generated correctly. This happened since ever, it's nothing that was introduced with RC6. I justed tested on a Linux system, and there I get a fatal error due to exceeding memory_limit during "Processing Procedural Page Element Name Conflicts": Sorting page elements...done Formatting @uses list...Building indexes... Fatal error: Allowed memory size of 268435456 bytes exhausted at /home/jan/cvs/p hp44/Zend/zend_hash.c:275 (tried to allocate 52 bytes) in /usr/share/php/PhpDocu mentor/phpDocumentor/ on line 1474 Call Stack: 0.0003 14736 1. {main}() /usr/bin/phpdoc:0 0.0008 22568 2. include() /usr/bin/phpdoc:37 0.2282 7522336 3. phpdocumentor_setup->createdocs() /usr/share/php/PhpD ocumentor/phpDocumentor/ 517.5416 237710696 4. phpdocumentor_intermediateparser->output() /usr/share /php/PhpDocumentor/phpDocumentor/ 528.7395 251154104 5. phpdocumentor_intermediateparser->_setupuseslist() /u sr/share/php/PhpDocumentor/phpDocumentor/ 528.7397 251195072 6. __dummyconverter->_createpkgelements() /usr/share/php /PhpDocumentor/phpDocumentor/ Test script: --------------- The command being used is: phpdoc -d framework -t api -i CVS/\* -o "HTML:frames:phphtmllib" -ti "framework" -dn horde -dc horde --pear The framework module can be checked out from Horde's CVS server ( or downloaded as a snapshot (framework-HEAD-...tar.gz from


 [2006-05-18 01:35 UTC] cellog (Greg Beaver)
is there any chance of a test script smaller than horde? :)
 [2006-05-18 03:03 UTC] jeichorn at php dot net (Joshua Eichorn)
This looks too me like standard phpDocumentor memory usage on large code bases. There might well be optimizations to make but the only short term fix i see is too not set a memory_limit of 256M in
 [2006-05-18 11:31 UTC] yunosh (Jan Schneider)
> is there any chance of a test script smaller than horde? Of course, but then the memory_limit wouldn't be hit. ;)
 [2006-05-18 11:32 UTC] yunosh (Jan Schneider)
> This looks too me like standard phpDocumentor memory usage on large code > bases. There might well be optimizations to make but the only short > term fix i see is too not set a memory_limit of 256M in Even a limit of 512M didn't suffice, some optimization seems really necessary.
 [2006-05-18 16:29 UTC] jeichorn at php dot net (Joshua Eichorn)
I don't think this is a case of simple optimizations. We started some work on a branch that uses sqllite for data storage that will get around this problem. Base PHP data structures are efficient and in a large app like this its really easy to get things in a state where no memory is released until PHP stops. I would expect something like Horde to use around a gig of ram. Memory optimizations patches are welcome, but I think on the current codebase you could spend days tweaking stuff without getting any results.
 [2006-07-03 16:05 UTC] ogmueller
would it be possible not to overwrite the memory limit settings in case the initial value (php.ini) is higher than 256MB? ( i would prefer not to change the source code and to have the change to increase the allowed memory size...
 [2006-10-03 02:10 UTC] seufert at gmail dot com (Chris Seufert)
I have this problem. Obviously no one is planning no fixing it. However there is an interim fix. Its outlined here. Basically just edit /usr/bin/pecl and add "-d memory_limit=-1" to the php command on the last line I think this would be the most elegant fix, for now.
 [2006-12-05 18:00 UTC] ashnazg at users dot sourceforge dot net (Chuck Burgess)
I submitted a Sourceforge patch last month that allows you to configure a max memory value in the phpDocumentor.ini file. The patch is at Here's how it works: - if you put a memory_limit value in phpDocumentor.ini, it is used... period... regardless of how big or how small in relation to php.ini or 256; - otherwise, the LARGER of php.ini's value OR the 256MB value is used. Oliver: If your php.ini setting is already >256, then the existing code should not be causing phpDocumentor to drop to the lower 256MB ceiling. However, using my patch will allow you to set the value to whatever you want it to be, using phpDocumentor.ini to do it.
 [2006-12-18 17:44 UTC] ashnazg at php dot net (Chuck Burgess)
Greg, should I consider committing patch #1588942 as a "fix" for this particular bug, or would that patch count as an enhancement ("feature") and require this bug to wait for a feature release before it gets committed?
 [2006-12-18 20:29 UTC] cellog (Greg Beaver)
the patch simply allows setting memory_limit, which does not in fact improve memory usage, so no, this is a separate and massive undertaking that is planned for 2.0
 [2007-01-10 20:59 UTC] ashnazg at php dot net (Chuck Burgess)
SF patch #1588942 is now committed to CVS, so memory_limit will now be configurable in the INI file.
 [2010-04-08 22:35 UTC] protatoe (pro tatoe)
Sorry to add to an old thread, but I was quiet surprised to see this still an issue 4 years after it was reported. Even at a 1GB of ram, it's still failing to parse out the documentation. This only started happening after recompiling with tokenizer support, because it was failing for different reasons with out.
 [2010-06-09 19:24 UTC] wcomnisky (William G. Comnisky)
I have the same problem (allowed memory size exhausted) while trying to generate the documentation of my models, generated by Propel (113 model classes, with their peers, map builders and base classes - 565 files). Ubuntu 9.10 PHP 5.2.10-2ubuntu6.4 with Suhosin-Patch 0.9.7 (cli) Zend Engine v2.2.0 with Xdebug v2.0.4 phpDocumentor version 1.4.3 Maximum memory usage set at 512M by phpDocumentor.ini using tokenizer Parser [exec] Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 35 bytes) in /usr/share/php/PhpDocumentor/phpDocumentor/ on line 303 [exec] [exec] Call Stack: [exec] 0.0006 57828 1. {main}() /usr/bin/phpdoc:0 [exec] 0.0011 66360 2. require('/usr/share/php/PhpDocumentor/phpDocumentor/') /usr/bin/phpdoc:40 [exec] 0.1359 9419524 3. phpDocumentor_setup->createDocs() /usr/share/php/PhpDocumentor/phpDocumentor/ [exec] 107.1463 533144076 4. phpDocumentorTParser->parse() /usr/share/php/PhpDocumentor/phpDocumentor/ [exec] 107.1516 530961380 5. phpDocumentorTParser->configWordParser() /usr/share/php/PhpDocumentor/phpDocumentor/ [exec] 107.1517 530961444 6. phpDocumentorTWordParser->setup() /usr/share/php/PhpDocumentor/phpDocumentor/ [exec] 107.1639 534709464 7. phpDocumentorTWordParser->addFileSource() /usr/share/php/PhpDocumentor/phpDocumentor/ [exec] 107.2731 536752240 8. phpDocumentorTWordParser->addSource() /usr/share/php/PhpDocumentor/phpDocumentor/ [exec] 107.2731 536752832 9. str_replace() /usr/share/php/PhpDocumentor/phpDocumentor/ [exec] [exec] Result: 255 (running with Ant)
 [2011-01-15 19:40 UTC] reinierk (Reinier Kleipool)
What I am missing from this discussion is WHY? WHY is memory usage so outrageous. I am compiling documentation for openbiz some 168764 lines of code in 695 files This consumes 580M of memory. That comes to ~1M per file and 3.6Kb per line of code! Surely this can be done much more efficient with less memory. Maybe its worth investigating where memory is used, where memory can be released etc...
 [2012-01-24 00:10 UTC] ashnazg (Chuck Burgess)
 [2012-09-01 00:46 UTC] ashnazg (Chuck Burgess)
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: ashnazg -Roadmap Versions: 2.0.0a1 +Roadmap Versions:
No more feature work on phpDocumentor 1.x. Check out the new phpDocumentor 2.x (