O que é mais rápido db_query, db_select ou EntityFieldQuery

Então, eu estou tentando descobrir o que é mais rápido, db_query, db_select ou EntityFieldQuery. Atualmente estou usando EntityFieldQuery. Estou pegando cerca de 1600 entradas de nós.

Sei que isso pode ser desgastante para o sistema, então só quero descobrir qual é a melhor opção para capturar 1600 nós. Economizar segundos ou mesmo milissegundos importaria muito com o aplicativo que estou construindo.

Agradecemos antecipadamente por suas respostas.

database

— Jorge Calderon
fonte

Você definiu o perfil?

— mpdonadio

Não tenho certeza do que você quer dizer. Você poderia elaborar um pouco?

— Jorge Calderon

O que você deve usar depende do que você está tentando fazer exatamente? Se você puder fornecer mais detalhes, poderemos ajudar. Se você estiver executando muitas consultas, db_query () é o mais rápido. No entanto, se você estiver carregando entidades com ele (entity_load), isso provavelmente não importa, porque o entity_load será lento ao carregar mais de 1600 entidades.

— donutdan4114

Há mais do que apenas a velocidade do código / consulta da consulta. Por exemplo, você precisa de acesso ao nó?

— ROOBY

@rooby - Sim, eu faço. Continuei usando EntityFieldQuery, mas para minhas necessidades, tenho que ter acesso a três campos personalizados nos nós. No entanto, a resposta abaixo ainda é a melhor, já que o raf deu alguns bons conselhos e números. O que era exatamente o que eu estava procurando.

— Jorge Calderon

Respostas:

Para responder sua pergunta resumidamente, db_query é o mais rápido! Aqui estão algumas razões, fatos e números compilados a partir de diferentes perguntas, fontes:

Um simples estudo desta questão, apresentou os seguintes resultados:

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()

e isto

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

Se você notar acima, o db_select faz mais chamadas de função e utiliza mais memória que o db_query.

Veja aqui os motivos pelos quais usar o db_select
Veja aqui os motivos pelos quais usar o EntityFieldQuery sobre db_select
Veja aqui a comparação de desempenho de db_query e db_select

Eu acho que a escolha deve ser baseada exclusivamente em suas necessidades. O EntityFieldQuery pode ser mais lento, mas oferece muitas vantagens, como sintaxe simples, armazenamento em campo que pode ser conectado, acoplamento flexível e muito mais.

— Raf
fonte

Era exatamente isso que eu estava procurando. Muito obrigado Raf.

— Jorge Calderon

Essa é uma péssima idéia para 1600 nós, não percorra as APIs e use o EntityFieldQuery. Você está otimizando a coisa errada.

Oi Chx, você poderia elaborar. Portanto, é necessário extrair 1600 nós. Eu já estou usando EntityFieldQuery, apenas tentando entender qual seria a má idéia. O que descobri é que o EntityFieldQuery é limitado em algumas áreas. Até agora não é nada que está me afetando. Enfim, estou ansioso para ouvir seus pensamentos.

— Jorge Calderon

Se você deseja apenas os dados do campo de todos os 1600 nós, o EFQE pode ser útil. Se você já possui o EFQ, poderá descobrir o que precisa consultando a página da sandbox.

— mikeytown2
fonte