A while ago someone join #php.pecl with some XDebug issues while using Doctrine. What ensued were a series of (very helpful) rants on the do's and don'ts in regards to large libraries, HTTP headers and maxclients settings in Apache. I have asked Rasmus permission to keep a log of the discussion and post them in my blog. In this first post I will provide a link and some commentary on Rasmus's points regarding Doctrine (note I left independent chatter in the log in order to not have any chance of me filtering the content, but there is very little of that so I hope the discussion is still easy enough to follow).
First up with the things Doctrine tries to do, its hard to get less lines of code. If the things it does are needed, thats another question. IMHO they are for a great number of situations. These mainly involve applications where you have to attach complex business logic to your stored data, especially if various different modules operate on the same data sets. In this situation you can either start using stored routines to ensure that all modules behave according to the common business logic, or you need to start using an ORM to be able to hook in and be able to attach business logic whenever someone messes with the data. This also gives you a lot of flexibility to meet changing requirements. My classic example is if your client decides at some point that certain data shall never be deleted but simply marked as deleted. With an ORM you can deal with this requirement in a single place, without an ORM you have to go through your entire codebase.
Another point I see where ORM's can actually out perform hand crafted SQL brings us back more clearly to the issue of development time vs. performance. With infinite development time, I would use assembler. Since none of us have this luxury, we balance things. With an ORM I go to one extreme in the LOC I pull in. However it gives me new ways for optimization I would not have otherwise (without a lot of development time). For example say I want to switch between pessimistic and optimistic locking? Or I want to try out a nested set algorithm to replace my materialized path implementation. All of this can be done very easily with an ORM, but usually mean a world of pain without one. Again the key assumption here is that multiple modules need to play with the same data.
At any rate, there are several general hints about making your code more byte code cache friendly that the Doctrine guys should implement. Some of them have already been scheduled for up coming versions, others will likely get added based on Rasmus comments. Better separation of the various Doctrine components, to let the user more easily pick and choose what he wants to use has been one of the key things I have been wanting to see happen for a long time. While I am at it, I guess its time to also state that my plans of taking over the Doctrine DBAL have largely gone without me making any actual contributions. Given with all the other things I am doing (well ok, Frisbee takes the bulk of my spare time), there is just not time to work on the Doctrine code base. This is really a pity, then again the community seems growing by the day. I do still follow the IRC channel and the mailing list to offer whatever advice I can.
[Update 16/04/2008 17:40 CEST]:
I have removed some off hand comments by Rasmus, that were more jokingly meant than to be taken serious. This is the kind of comment you make inside an IRC discussion, but that can and will likely be ripped out of its original casual context by way of search engines. Its only 3 lines, the original topic itself is not altered in anyway. I hope you all approve that its more important to get what is left online, rather than getting to the point where its simply no longer feasible for anyone to let anyone posts logs about interesting discussions.
What strikes me the most out of that conversation is the mention of MacClients 32.. This seems really low, I'm on 200..
I'm wondering if I should tweak other settings..