# Doctrine ORM Hydration Performance Optimization

DevFeed: [Doctrine ORM Hydration Performance Optimization](<https://devfeed.tech/articles/doctrine-orm-hydration-performance-optimization-21141.md>)

Original publisher: [Read original article](<https://ocramius.github.io/blog/doctrine-orm-optimization-hydration/>)

Published: 2015-04-13T00:00:00Z

Content type: article

Language: en

Sources: [Marco Pivetta](<https://devfeed.tech/sources/marco-pivetta.md>)

Topics: [Object-relational mapping](<https://devfeed.tech/topics/orm.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [PHP](<https://devfeed.tech/topics/php.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [database](<https://devfeed.tech/tags/database.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [orm](<https://devfeed.tech/tags/orm.md>), [performance](<https://devfeed.tech/tags/performance.md>), [performance-optimization](<https://devfeed.tech/tags/performance-optimization.md>), [php](<https://devfeed.tech/tags/php.md>), [sql](<https://devfeed.tech/tags/sql.md>)

## AI overview

This article explains how Doctrine ORM hydrates database results into objects and why hydration becomes more expensive for complex result sets. It examines the cost of mapping rows, handling joined records, skipping empty associations, and de-duplicating repeated records, with attention to CPU and memory usage.

## Source excerpt

PRE-REQUISITE: Please note that this article explains complexity in internal ORM operations with the Big-O notation. Consider reading this article, if you are not familiar with the Big-O syntax. What is hydration? Doctrine ORM, like most ORMs, is performing a process called Hydration when converting database results into objects. This process usually involves reading a record from a database result and then converting the column values into an object's properties. Here is a little pseudo-code snippet that shows what a mapper is actually doing under the hood: <?php $results = []; $reflectionFields = $mappingInformation->reflectionFields(); foreach ($resultSet->fetchRow() as $row) { $object = new $mappedClassName; foreach ($reflectionFields as $column => $reflectionField) { $reflectionField->setValue($object, $row[$column]); } $results[] = $object; } return $results; That's a very basic example, but this gives you an idea of what an ORM is doing for you. As you can see, this is an O(N) operation (assuming a constant number of reflection fields). There are multiple ways to speed up this particular process, but we can only remove constant overhead from it, and not actually reduce it to something more efficient. When is hydration expensive? Hydration starts to become expensive with complex resultsets. Consider the following SQL query: SELECT u.id AS userId, u.username AS userUsername, s.id AS socialAccountId, s.username AS socialAccountUsername, s.type AS socialAccountType FROM user u LEFT JOIN socialAccount s ON s.userId = u.id Assuming that the relation from user to socialAccount is a one-to-many, this query retrieves all the social accounts for all the users in our application A resultset may be as follows: userId userUsername socialAccountId socialAccountUsername socialAccountType 1 ocramius@gmail.com 20 ocramius Facebook 1 ocramius@gmail.com 21 @ocramius Twitter 1 ocramius@gmail.com 22 ocramiusaethril Last.fm 2 grandpa@example.com NULL NULL NULL 3 grandma@example.co