15

So I'm trying to find out what is faster db_query, db_select, or EntityFieldQuery. Currently I'm using EntityFieldQuery. I'm grabbing about 1600 node entries.

I realize this can be taxing on the system so I just want to figure out which is the best option to grab 1600 nodes. Shaving off seconds or even milliseconds would matter a lot with the application I'm building.

Thanks in advance for your answers.

  • Have you profiled it? – mpdonadio Sep 13 '14 at 21:21
  • Not sure what you mean. Could you elaborate a little? – Jorge Calderon Sep 13 '14 at 21:38
  • What you should use depends on what you're trying to do exactly? If you can give more detail we might be able to help. If you are running a lot of queries, db_query() is the fastest. However, if you are loading entities with it (entity_load) than it probably doesn't matter, because entity_load will be slow when loading 1600+ entities. – donutdan4114 Sep 13 '14 at 22:31
  • 1
    There is more to it than just the speed of the query code/query. For example do you need node access? – rooby Sep 17 '14 at 1:14
  • @rooby - Yeah I do. I kept using EntityFieldQuery but for my needs, I have to have access to three custom fields in the nodes. However, the answer below is still the best answer since raf gave some pretty good advice and numbers. Which was exactly what I was looking for. – Jorge Calderon Sep 17 '14 at 13:12
24

To answer your question in short, db_query is the fastest! Here are some reasons, facts and figure compiled from different questions, sources:

A simple googling of this question, come up with following results:

For simple queries, db_query() is 22% faster than db_select()
For simple queries, db_query() is 124% faster than EFQ
For queries with two joins, db_query() is 29% faster than db_select()

and this

db_query():

Total Incl. Wall Time (microsec):   796 microsecs
Total Incl. CPU (microsecs):    0 microsecs
Total Incl. MemUse (bytes): 123,352 bytes
Total Incl. PeakMemUse (bytes): 124,248 bytes
Number of Function Calls:   38

db_select()

Total Incl. Wall Time (microsec):   1,118 microsecs
Total Incl. CPU (microsecs):    0 microsecs
Total Incl. MemUse (bytes): 425,216 bytes
Total Incl. PeakMemUse (bytes): 436,392 bytes
Number of Function Calls:   88

If you notice above db_select makes more function calls and utilize more memory than db_query.

  1. See here for reasons on why to use db_select
  2. See here for reasons on why to use EntityFieldQuery over db_select
  3. See here for performance comparison of db_query and db_select

I guess the choice should be solely based on your requirements. EntityFieldQuery might be slower but, offers many advantages such as simple syntax, field storage is pluggable, loose coupling and many more.

  • 1
    This is exactly what I was looking for. Thanks a bunch Raf. – Jorge Calderon Sep 14 '14 at 2:30
1

That's a very bad idea there, for 1600 nodes, don't go around the APIs and use EntityFieldQuery . You are optimizing the wrong thing.

  • Hi Chx, could you elaborate. So bottom line, 1600 nodes need to be pulled. I'm already using EntityFieldQuery so just trying to understand what the bad idea would be. What I have found is that EntityFieldQuery is limiting in some areas. So far it's nothing that is affecting me. Anyway, looking forward to hearing your thoughts. – Jorge Calderon Sep 15 '14 at 15:51
1

If you just want the field data from all 1600 nodes, EFQE might be helpful. If you already have the EFQ you should be able to figure out what you need by looking at the sandbox page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.