Was ist schneller db_query, db_select oder EntityFieldQuery

Ich versuche also herauszufinden, was schneller ist als db_query, db_select oder EntityFieldQuery. Derzeit verwende ich EntityFieldQuery. Ich greife nach ungefähr 1600 Knoteneinträgen.

Mir ist klar, dass dies das System belasten kann, und ich möchte nur herausfinden, welche Option am besten für 1600 Knoten geeignet ist. Bei der Anwendung, die ich erstelle, ist es sehr wichtig, Sekunden oder sogar Millisekunden zu sparen.

Vielen Dank im Voraus für Ihre Antworten.

database

— Jorge Calderon
quelle

Hast du es profiliert?

— mpdonadio

Nicht sicher was du meinst. Könnten Sie etwas näher darauf eingehen?

— Jorge Calderon

Was Sie verwenden sollten, hängt davon ab, was Sie genau tun möchten? Wenn Sie weitere Details angeben können, können wir Ihnen möglicherweise weiterhelfen. Wenn Sie viele Abfragen ausführen, ist db_query () die schnellste. Wenn Sie jedoch Entities damit laden (entity_load), spielt dies wahrscheinlich keine Rolle, da entity_load beim Laden von über 1600 Entities langsam ist.

— donutdan4114

Es steckt mehr dahinter als nur die Geschwindigkeit des Abfragecodes / der Abfrage. Benötigen Sie zum Beispiel Knotenzugriff?

— Rooby

@rooby - Ja, das tue ich. Ich habe weiterhin EntityFieldQuery verwendet, muss aber für meine Anforderungen Zugriff auf drei benutzerdefinierte Felder in den Knoten haben. Die Antwort unten ist jedoch immer noch die beste Antwort, da Raf einige ziemlich gute Ratschläge und Zahlen gab. Welches war genau das, wonach ich gesucht habe.

— Jorge Calderon

Antworten:

Um Ihre Frage kurz zu beantworten: db_query ist die schnellste! Hier sind einige Gründe, Fakten und Zahlen aus verschiedenen Fragen, Quellen zusammengestellt:

Wenn Sie diese Frage einfach googeln, erhalten Sie die folgenden Ergebnisse:

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

und das

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

Wenn Sie oben bemerken, führt db_select mehr Funktionsaufrufe durch und belegt mehr Speicher als db_query.

Sehen Sie hier aus Gründen, warum die Verwendung db_select
Sehen Sie hier aus Gründen, warum EntityFieldQuery über db_select verwenden
Sehen Sie hier für Performance - Vergleich von db_query und db_select

Ich denke, die Auswahl sollte sich ausschließlich nach Ihren Anforderungen richten. EntityFieldQuery ist zwar langsamer, bietet jedoch viele Vorteile wie einfache Syntax, steckbare Feldspeicherung, lose Kopplung und vieles mehr.

— Raf
quelle

Genau das habe ich gesucht. Vielen Dank Raf.

— Jorge Calderon

Das ist eine sehr schlechte Idee, bei 1600 Knoten sollten Sie die APIs nicht umgehen und EntityFieldQuery verwenden. Sie optimieren das Falsche.

Hallo Chx, könntest du das näher erläutern? Unterm Strich müssen also 1600 Knoten gezogen werden. Ich benutze bereits EntityFieldQuery, um zu verstehen, was die schlechte Idee wäre. Was ich festgestellt habe, ist, dass EntityFieldQuery in einigen Bereichen einschränkt. Bisher betrifft mich nichts. Wie auch immer, ich freue mich darauf, Ihre Gedanken zu hören.

— Jorge Calderon

Wenn Sie nur die Felddaten von allen 1600 Knoten benötigen , ist EFQE möglicherweise hilfreich. Wenn Sie bereits über den EFQ verfügen, sollten Sie in der Lage sein, anhand der Sandbox-Seite herauszufinden, was Sie benötigen.

— mikeytown2
quelle