Re: Re: Phpdocumentor memory usage

Hi all, This is definitely one of the things planned for the next major version (2.x), that is, to make phpDocumentor work a little more like the make command. I'm hoping to make a standard interface between phpDocumentor and storage methods, and then a system of plugging in drivers for storage methods, so that disk cache can be used, or MDB-based cache, or even (for the insane) a remote SOAP-based cache or other method that we've not thought of yet. This is not even on the drawing board yet, but is definitely in brainstorm stage. I will investigate the use of dataobjects. The only thing I want to ensure is that phpDocumentor doesn't depend on external entities to work, as much as possible, so that it is a run-out-of-the-box tool. As PEAR matures, I want to make it an option to depend on the PEAR classes that are used, like HTML_TreeMenu, but not a requirement. Same with any non-standard C extensions. So, if phpDocumentor uses DB_DataObjects, for example, I'll include the source for DB_DataObjects bundled as an option, separate from PEAR, but also have a release available that depends on PEAR being installed. Does this strike everyone as reasonable? Anyone with better ideas, I'd love to hear them. I've started implementing some of the changes in the peardoc2 converter, as well, although the work is in transition. Greg Alan Knowles wrote:

I did do some testing with a fork of phpcodedoc (which did C#) to store the tokens and class/function/docs etc. in mysql so it only parses files that have changed. and renders from the database rather than memory. It obviously slows down the parsing stage on the initial build - but solves memory issues. - I was also planning to do output caching - so it only outputted files that had changed (or contained data that had changed..) - it doesnt take too long to do if you are using objects to store data - to convert them to dataobjects. Anyway thought it might help Regards Alan Tal Peer wrote:

On Thu, 20 Mar 2003, Greg Beaver wrote:

Hi Tal, This is a consideration I've thought about. Unfortunately, I don't know C as well as PHP, although I'm trying to get a handle on how the internals of PHP work, and don't have a unix platform at home to play around with it. I also have no facility to compile C code on windows (meaning no big $$$ to buy msvc or equivalent), but these problems won't stop us from accepting help from users who have a C compiler or more C experience, so that is a good idea, even if only the most memory-intensive sections are written in C, and the converters are written in PHP, which would work nicely for extensibility.

I'm willing to help. I think that making the memory eating parts an extension and leaving the lighter stuff in userland is indeed thr right solution. We need to do some profiling on the source to get the whole picture. Tal

Greg Tal Peer wrote:

You could rewrite it in C (still the memory signature will be big, but not as big as now, since zvals are bigger than char ** :)

-- Tal Peer tal@php.net