Out of curiosity what are you doing in PHP where memory usage is an issue? PHP's standard life cycle, while having numerous disadvantages, avoids a lot of problems with memory usage.
It's a rather different beat, but you might checkout Propel (http://propelorm.org) for a different take on a PHP ORM. It has a static build phase unlike Doctrine which turns some people off, but if you can get past that it's a rather nice ORM.
If you think that your project is going to grow into a substantial code base, I would NOT recommend Propel.
A lot about their active record implementation violates POLA with various gotchas and code generation gets tedious and unwieldy with models that contain many fields or relations.
Say you want to add a product to an existing order in the database...
$orderProduct = new OrderProduct();
$order = OrderPeer::retrieveByPK(1);
$order->addOrderProduct($orderProduct);
Now, if ANYWHERE after this point in the code, something calls $order->getOrderProducts() before you call $order->save() (like a validation routine or something) you will lose that new OrderProduct and it will not be persisted.
It's bit me more than once, especially as you start to spread code around that depends on traversing the relationships - can be a very tricky bug to spot.
Propel's implementation of related collections definitely could use some improvement. In your example, you wouldn't necessarily lose your new object, it just wouldn't be persisted through a call to the parent order to save. My general habit is to call save on a newly created object directly, and as soon as possible. Regardless, I definitely agree this is one (and there are some other points) where Propel definitely has rough edges.
With this project in particular, each time someone hits the main page there are 6 php scripts executed in parallel. I was hitting some limits with my VPS during those spikes.
Yes with some complicated work patterns, Doctrine becomes memory and cpu/time hungry. I've been struggling with doctrine issues with our customers event portal. Most of the time we have to turn back into array based hydration. Even then time/cpu intensiveness is still there.
I think it's pretty important to figure out what you expect from a framework.
If you want to make it easier for other people to come on, perhaps open up to an ecosystem of open source contribution, you want a framework with broad appeal. Yii or Drupal would be good choices.
If you want a solid foundation, that you personally will benefit from, you either want something that is well engineered (perhaps even slightly over engineered) or something really minimal, that doesn't get in the way. Depending on you own experience and/or taste.
I started using Kohana after moving on from CI, but these days, I don't do as much PHP development. It's mostly Node.js development now.
I did start rebuilding this in Kohana a few months ago with the intention of rebuilding it as a less panel-y looking interface, but ended up scrapping the project.
