What is the overhead of using Doctrine?

Posted on

Question :

A few days ago I’ve been arguing with some co-workers about performance and high availability.

In the middle of the discussion one of the points raised was that when reaching a certain number of requests, Doctrine ORM becomes a bottleneck in the application, and we would have to use PDO to maintain performance.

I could not accept the argument, since gigantic projects like PornHub use Symfony with Doctrine and can handle a monstrous number of requests.

It is not enough to have projects that prove the efficiency of the library, there is a whole question of syntax and productivity involved. When using ORM we are gaining a lot of productivity because we avoid repetitive codes that can lead to errors.

Given these facts, how can we correctly measure the difference of overhead in using pure PDO and using Doctrine ORM?

Important : Although the question is based on my experience of using the library, my goal is technical, so I want to receive answers that demonstrate the technical advantage and disadvantage of using each tool. >

Answer :

I do not believe that a library has only negative points, nor does it have only good points.

When I see programmers doing this type of comment, I usually ignore them.

The important things to ask yourself is: What is your experience to say this?

Show only the negatives of something is to be incoherent and partial.

I would also say that there is in some an eternal war of those who do not use frameworks or libraries wanting to converse who uses to stop using, or vice versa.

The Doctrine

In my point of view, Doctrine is a fairly robust database framework and one that, as stated in the question, prevents code repetition.

In addition, it relies on a relational model, which is often needed for better organization of database access / record in your application – something that does not exist using PDO pure.

And the performance?

On the question of performance, I have to say: Somehow you will have to pay for your choice .

If you choose to worry so much about performance to the point that you stop using Doctrine, you’ll have to do a lot of work or opt for another library, but then you’d have to gauge whether the trades make up for the time you spend.

On the other hand, by opting to use only PDO , you would be spending a lot of time remapping queries manually.

So, weigh both things in the balance and decide which side you’re going to stay in.

I stopped for a long time to worry about micro-optimizations.

I think things should be weighed on the scales. It’s easy to say that a truck is too big to fit in a garage, but forget that it can carry a ton of things.

What I mean is that you have to evaluate whether your project will actually benefit from using an X or Y library.

A jargon I see among programmers, which I agree with, is: Why use a bazuka to kill an ant? .

I do not think it would make sense to use Doctrine to make a simple web site, which has only three tables for query. But if you’re going to do something more robust / scalable, I’d highly recommend using it.


Some programmers may give opinions saying it can generate Overhead, but this was based on what?

How big is the application they have already developed? What is the scenario?

With the pardon of the joke, but any library you use will use more memory / resources in your application than if you did not use . But at the end of the day, without them, you’d have a bunch of stuff to write for your application.

Another detail: Some people often flag something as bad, because they misused the tool and, instead of admitting that it was wrong, they blame the framework (I even fell into that error :)).

In addition, Doctrine is a framework (not to say the only) of the most robust I know for PHP database.

Another detail is that if you feel you do not pay for Doctrine’s ORM, you can still use other features, such as Doctrine Query Builder, which is a Doctrine query builder that can also help you avoid code repetition.


Leave a Reply

Your email address will not be published. Required fields are marked *