The only way manual processing of the data from the db could take as long as doctrine hydration is if it's written poorly. An app developer who knows how to wri

The only way manual processing of the data from the db could take as long as doctrine hydration is if it's written poorly. An app developer who knows how to write apps properly would never do hydration or any of the stupidity doctrine does. Why would one map database rows into objects in the first place? I've rewritten huge swaths of one of our doctrine apps getting a roughly 5x to 10x improvement in speed and I left a lot of optimizations on the table while still providing a general purpose serializer that uses doctrine's meta data behind the scenes. As for dbal, I think the overhead is in statement preparation and parameter expansion (for array params) and it can be avoided by using the native functions, though that overhead was never 10x for me.