Cosa è più veloce db_query, db_select o EntityFieldQuery

Quindi sto cercando di scoprire cosa è più veloce db_query, db_select o EntityFieldQuery. Attualmente sto usando EntityFieldQuery. Sto afferrando circa 1600 voci di nodo.

Mi rendo conto che questo può essere tassativo sul sistema, quindi voglio solo capire qual è l'opzione migliore per catturare 1600 nodi. Rasatura di secondi o addirittura millisecondi importerebbe molto con l'applicazione che sto costruendo.

Grazie in anticipo per le tue risposte.

database

— Jorge Calderon
fonte

L'hai profilato?

— mpdonadio

Non sono sicuro cosa intendi. Potresti elaborare un po '?

— Jorge Calderon,

Quello che dovresti usare dipende da cosa stai cercando di fare esattamente? Se puoi fornire maggiori dettagli, potremmo essere in grado di aiutarti. Se stai eseguendo molte query, db_query () è il più veloce. Tuttavia, se si caricano entità con esso (entity_load) di quanto probabilmente non importa, poiché entity_load sarà lento quando si caricano più di 1600 entità.

— donutdan4114,

C'è di più oltre alla velocità della query codice / query. Ad esempio, hai bisogno dell'accesso al nodo?

— Rooby,

@rooby - Sì, lo so. Ho continuato a utilizzare EntityFieldQuery ma per le mie esigenze, devo avere accesso a tre campi personalizzati nei nodi. Tuttavia, la risposta di seguito è ancora la migliore risposta poiché raf ha dato alcuni consigli e numeri piuttosto buoni. Era esattamente quello che stavo cercando.

— Jorge Calderon,

Risposte:

Per rispondere alla tua domanda in breve, db_query è il più veloce! Ecco alcuni motivi, fatti e cifre compilati da diverse domande, fonti:

Un semplice googling di questa domanda, fornisce i seguenti risultati:

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 questo

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 noti sopra db_select, effettua più chiamate di funzione e utilizza più memoria di db_query.

Vedi qui per motivi sul perché usare db_select
Vedi qui per motivi sul perché usare EntityFieldQuery su db_select
Vedi qui per il confronto delle prestazioni di db_query e db_select

Immagino che la scelta debba basarsi esclusivamente sulle tue esigenze. EntityFieldQuery potrebbe essere più lento, ma offre molti vantaggi come la sintassi semplice, l'archiviazione sul campo è innestabile, l'accoppiamento libero e molti altri.

— Raf
fonte

Questo e 'esattamente quello che stavo cercando. Grazie mille Raf.

— Jorge Calderon,

Questa è una pessima idea lì, per 1600 nodi, non andare in giro per le API e usare EntityFieldQuery. Stai ottimizzando la cosa sbagliata.

Ciao Chx, potresti approfondire. Quindi, in conclusione, devono essere estratti 1600 nodi. Sto già usando EntityFieldQuery quindi sto solo cercando di capire quale sarebbe la cattiva idea. Quello che ho scoperto è che EntityFieldQuery sta limitando in alcune aree. Finora non è niente che mi sta colpendo. Comunque, non vedo l'ora di sentire i tuoi pensieri.

— Jorge Calderon,

Se desideri solo i dati del campo da tutti i 1600 nodi, EFQE potrebbe essere utile. Se hai già l'EFQ dovresti essere in grado di capire di cosa hai bisogno guardando la pagina sandbox.

— mikeytown2
fonte