Re: memory usage issues in PEAR 1.4.0

Alan Knowles wrote:

I guess what you are aluding to below is that PEAR needs to go on a diet. - and without a good understanding of it, it's difficult to know where that pruning could happen.

I'm alluding to precisely the opposite - PEAR can't go on a diet without a clean break from the past. PEAR2 can go on a diet for these reasons. I'm alluding to the fact that the only way to make things run with less memory is to drop ALL of the new features, not just some of them. Everything is inter-connected. Something that solves one problem solves another. Channels can't work unless the robust dependency stuff is there to validate cross-channel dependencies and to handle large dependency trees. The robust dependency stuff can't work without package.xml 2.0, which can't work without lots of validation stuff and the registry/config interdependence. We're only talking about the difference between 8MB and 11MB - is this really worth any sweat and tears to fix?

The only other idea the seems to come from looking at the code is that when packaging, storing a serialized verison of the xml file as well as the orginal, so XML parsing is only needed on old files..

This would actually increase memory consumption, unfortunately, as we would need to add code to check for the serialized versions.

This could possibly remove alot of XML parsing, dependancy parsing validation etc. - How much validation is actually done on install BTW?

Quite a bit, to make sure that packages that are packaged with rogue older PEAR versions don't cause real problems, for instance. Every needed element is checked to make sure it is there, and unlike PEAR 1.3.5, every aspect of the file tags including the tasks and <replace> are validated on install-time. Greg P.S. I started playing around with a simplexml-based package.xml parser/validator, and it would just be about a million times faster and simpler. It would also be nice to save the registry as xml instead of using serialize(), so that hand-editing is possible, and corruption is easy to fix. Configuration stored as an .ini file for the same reasons would be great.