Quoi de plus rapide db_query, db_select ou EntityFieldQuery

J'essaie donc de découvrir ce qui est plus rapide db_query, db_select ou EntityFieldQuery. Actuellement, j'utilise EntityFieldQuery. J'attrape environ 1600 entrées de nœuds.

Je me rends compte que cela peut être un fardeau pour le système, donc je veux juste savoir quelle est la meilleure option pour saisir 1600 nœuds. Raser des secondes ou même des millisecondes importerait beaucoup avec l'application que je construis.

Merci d'avance pour vos réponses.

database

— Jorge Calderon
source

L'avez-vous profilé?

— mpdonadio

Pas sûr de ce que vous voulez dire. Pourriez-vous élaborer un peu?

— Jorge Calderon

Ce que vous devez utiliser dépend de ce que vous essayez de faire exactement? Si vous pouvez donner plus de détails, nous pourrons peut-être vous aider. Si vous exécutez un grand nombre de requêtes, db_query () est la plus rapide. Cependant, si vous chargez des entités avec lui (entity_load), cela n'a probablement pas d'importance, car entity_load sera lent lors du chargement de plus de 1600 entités.

— donutdan4114

Il y a plus que la vitesse du code / de la requête. Par exemple, avez-vous besoin d'un accès au nœud?

— rooby

@rooby - Ouais je fais. J'ai continué à utiliser EntityFieldQuery mais pour mes besoins, je dois avoir accès à trois champs personnalisés dans les nœuds. Cependant, la réponse ci-dessous est toujours la meilleure réponse, car raf a donné de très bons conseils et des chiffres. C'était exactement ce que je cherchais.

— Jorge Calderon

Réponses:

Pour répondre à votre question en bref, db_query est le plus rapide! Voici quelques raisons, faits et chiffres compilés à partir de différentes questions, sources:

Une simple recherche sur Google de cette question donne les résultats suivants:

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

et ça

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 vous remarquez ci-dessus, db_select effectue plus d'appels de fonction et utilise plus de mémoire que db_query.

Voir ici pour savoir pourquoi utiliser db_select
Voir ici pour savoir pourquoi utiliser EntityFieldQuery sur db_select
Voir ici pour la comparaison des performances de db_query et db_select

Je suppose que le choix devrait être uniquement basé sur vos besoins. EntityFieldQuery peut être plus lent, mais offre de nombreux avantages tels qu'une syntaxe simple, le stockage sur le terrain est enfichable, un couplage lâche et bien d'autres.

— Raf
source

Ceci est exactement ce que je cherchais. Merci beaucoup Raf.

— Jorge Calderon

C'est une très mauvaise idée là-bas, pour 1600 nœuds, ne contournez pas les API et n'utilisez pas EntityFieldQuery. Vous optimisez la mauvaise chose.

Salut Chx, pourriez-vous élaborer. Donc, en fin de compte, 1600 nœuds doivent être retirés. J'utilise déjà EntityFieldQuery donc j'essaie juste de comprendre quelle serait la mauvaise idée. Ce que j'ai trouvé, c'est que EntityFieldQuery limite dans certains domaines. Jusqu'ici ce n'est rien qui m'affecte. Quoi qu'il en soit, j'ai hâte d'entendre vos pensées.

— Jorge Calderon,

Si vous voulez juste les données de champ des 1600 nœuds, EFQE peut être utile. Si vous avez déjà l'EFQ, vous devriez être en mesure de déterminer ce dont vous avez besoin en consultant la page sandbox.

— mikeytown2
source