Re: phpdocumentor memory issue

Hi Greg, Can't wait for 2.0 then :-) By the way, it would be nice to have a brief intro to using phpdocumentor to generate peardoc2 in the Developers Guide. I tried the options that were mentioned in the pear-doc mailing list, but then I don't get any inherited methods and properties. Specifically, I'd like to generate the docs for HTML_Page, which inherits from HTML_Common. Therefore, the methods (things like setTabs, etc) should also appear for HTML_Page. How do I go about this? Klaus > -------- Original Message -------- > Subject: Re: phpdocumentor memory issue > Date: Mon, 03 Nov 2003 11:59:38 -0500 > From: Greg Beaver <greg@chiaraquartet.net> > To: Klaus Guenther <klaus@capitalfocus.org> > References: <032c01c3a216$72fb7c10$5800a8c0@desk> > > > > Hi Klaus, > > The internal database that phpDocumentor uses in order to support some > of the significant features in version 1.x takes up a tremendous amount > of memory. In order to generate the full documentation for PEAR at > phpdorks.net, Josh told me it peaked at 800 MB of memory usage. > phpDocumentor itself requires about 120-220 depending on settings > (sourcecode=on takes up lots of memory). > > The tradeoff is between memory usage and speed. On slower processors, > it can take days to generate docs if we use lots of disk access. > > However, the rewrite which is currently taking place to create > phpDocumentor 2.0 will fix these issues using some advanced caching for > larger projects - the only time it will take any amount of time will be > the first parse, and it will never take a large amount of memory, as we > will be saving things in a database. Of course, this requires extra > setup, so the default will still be to keep everything in memory, as > this is much faster for small projects (the majority of our users). > > Hope this helps in understanding what is going on. We have to keep > track of every single item including line number, documentation, and so > on. Plus an in-memory database of information for internal linking must > be maintained (think LARGE array), and also the generation of indexes > (both for each package, and all items parsed) temporarily take up a huge > amount of memory (also a large array) before they are written to disk. > Memory cannot be easily purged in case there are multiple output formats > being generated at once. > > All of these issues will be easily resolved in 2.0 :) > > Greg >