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.
[0]. http://symfony.com/ [1]. http://silex.sensiolabs.org/ [2]. http://www.doctrine-project.org/