BenchMark Limbo with ORMs

So the story goes like this….

I have been building a business model and planning out a SaaS application for a future company I am building.

In the process I have been looking at frameworks, ORMs, DBALs, etc… to speed up the build process.

At the same time I have had some concerns.

  1. Memory usage
  2. Process usage
  3. Load time
  4. Learning curve

Learning curve being the smallest issue since all any of the above  (quick build options) are just OOP PHP, but none the less you have to learn their code.

So I have really been struggling with this part. Use quick build options, don’t use them????

So today I decided to do a quick benchmark, nothing special, just load time and memory usage.

I have a MySQL database with 240,000 records in it.

I chose to use Propel ORM because I really like it, but the following benchmark has me in limbo bit…

KEEP in mind, this is not a competition between ORMs or frameworks.

This is just between an ORM which I chose Propel and raw PHP –> MySQL.

Here is the outcome of the benchmarks,

———————————————————————-
ORM results Propel Hydration Demand was used.
———————————————————————-

20,000 Records, APC Opcode Cache on
Load Time: 4.040 seconds. • Memory Usage: 1.03 MiB
Peak Memory Usage: 1.050041 MiB

100,000 Records, APC Opcode Cache on
Load Time: 17.985 seconds. • Memory Usage: 1.03 MiB
Peak Memory Usage: 1.050362 MiB

100,000 Records, APC Opcode Cache off
Load Time: 17.936 seconds. • Memory Usage: 3.32 MiB
Peak Memory Usage: 3.344589 MiB

———————————————————————-
           Raw code
———————————————————————-

20,000 Records, APC Opcode Cache on
Load Time: 0.916 seconds. • Memory Usage: 0.33 MiB
Peak Memory Usage: 0.355274 MiB

100,000 Records, APC Opcode Cache on
Load Time: 2.392 seconds. • Memory Usage: 0.33 MiB
Peak Memory Usage: 0.355274 MiB

100,000 Records, APC Opcode Cache off
Load Time: 2.161 seconds. • Memory Usage: 0.33 MiB
Peak Memory Usage: 0.355274 MiB

So the results are a bit twisted. Was not what I was expecting, higher memory Yes, load time I thought would have been way better.

Also NOTE that this is not an application being benchmarked, it is just one query grabbing records from one table!

While 3.3MG of memory is not a lot to worry about, consider you still need all of your application code which will be more code than the ORM.
18 seconds to collect the data, well, thats just disappointing!

Where do I go from here? Well, I’m not sure.

This application will be huge and have what is planned a large user base.

Saving on resources, load time and scaling is KEY.

I know I can build a simple DBAL that will out perform the above ORM results, so I think that is the direction to take.

What I have found out is that ORM’s and FrameWorks are specifically for rapid development.

If I am going to chew up resources with them on a large scale application, then it is not worth using it.

Using some ideas from certain areas is about as far as I can go for this app, the rest will have to be hand written PHP that will be used in the app.

As a side note, notice the results have APC Opcode Cache on/off, APC Opcode Cache is awesome 🙂

I think ORMs like Propel and Frameworks like CodeIgniter which I really like both and they have a place in development.

If the application has a scaling limit, then thats where I would use them.

But I don’t think this app is the place.