¿Qué es más rápido db_query, db_select o EntityFieldQuery?

Así que estoy tratando de averiguar qué es más rápido db_query, db_select o EntityFieldQuery. Actualmente estoy usando EntityFieldQuery. Estoy agarrando alrededor de 1600 entradas de nodo.

Me doy cuenta de que esto puede ser gravoso para el sistema, así que solo quiero descubrir cuál es la mejor opción para obtener 1600 nodos. Reducir segundos o incluso milisegundos importaría mucho con la aplicación que estoy creando.

Gracias de antemano por sus respuestas.

database

— Jorge Calderon
fuente

¿Lo has perfilado?

— mpdonadio

No estoy seguro de lo que quieres decir. ¿Podrías elaborar un poco?

— Jorge Calderón

¿Qué debe usar depende de lo que está tratando de hacer exactamente? Si puede dar más detalles, podríamos ayudarlo. Si está ejecutando muchas consultas, db_query () es el más rápido. Sin embargo, si está cargando entidades con él (entity_load), probablemente no importe, porque entity_load será lento al cargar más de 1600 entidades.

— donutdan4114

Hay más que solo la velocidad del código de consulta / consulta. Por ejemplo, ¿necesita acceso a nodos?

— rooby

@rooby - Sí, lo hago. Seguí usando EntityFieldQuery pero para mis necesidades, tengo que tener acceso a tres campos personalizados en los nodos. Sin embargo, la respuesta a continuación sigue siendo la mejor respuesta ya que raf dio algunos buenos consejos y números. Que era exactamente lo que estaba buscando.

— Jorge Calderón

Respuestas:

Para responder a su pregunta en resumen, db_query es el más rápido. Aquí hay algunas razones, hechos y cifras compilados de diferentes preguntas, fuentes:

Una simple búsqueda en Google de esta pregunta, ofrece los siguientes 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()

y esto

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

Si observa lo anterior, db_select realiza más llamadas a funciones y utiliza más memoria que db_query.

Consulte aquí por razones sobre por qué usar db_select
Consulte aquí los motivos por los que debe utilizar EntityFieldQuery sobre db_select
Consulte aquí para comparar el rendimiento de db_query y db_select

Supongo que la elección debe basarse únicamente en sus requisitos. EntityFieldQuery puede ser más lento, pero ofrece muchas ventajas, como la sintaxis simple, el almacenamiento de campo es conectable, el acoplamiento suelto y muchos más.

— Raf
fuente

Esto es exactamente lo que estaba buscando. Muchas gracias Raf.

— Jorge Calderón

Esa es una muy mala idea, para 1600 nodos, no rodee las API y use EntityFieldQuery. Estás optimizando la cosa equivocada.

Hola Chx, ¿podrías explicarlo? Por lo tanto, es necesario extraer 1600 nodos. Ya estoy usando EntityFieldQuery, así que solo trato de entender cuál sería la mala idea. Lo que he encontrado es que EntityFieldQuery es limitante en algunas áreas. Hasta ahora no es nada lo que me está afectando. De todos modos, espero escuchar sus pensamientos.

— Jorge Calderón

Si solo desea los datos de campo de los 1600 nodos, EFQE podría ser útil. Si ya tiene el EFQ, debería poder averiguar qué necesita mirando la página de sandbox.

— mikeytown2
fuente