Co jest szybsze db_query, db_select lub EntityFieldQuery

Próbuję więc dowiedzieć się, co jest szybsze db_query, db_select lub EntityFieldQuery. Obecnie używam EntityFieldQuery. Zbieram około 1600 pozycji węzłów.

Zdaję sobie sprawę, że może to obciążać system, więc chcę po prostu dowiedzieć się, która opcja jest najlepsza do przechwycenia 1600 węzłów. Odgrywanie sekund, a nawet milisekund ma duże znaczenie w aplikacji, którą tworzę.

Dzięki z góry za odpowiedzi.

database

— Jorge Calderon
źródło

Czy profilowałeś to?

— mpdonadio

Nie wiem co masz na myśli. Czy mógłbyś trochę rozwinąć?

— Jorge Calderon,

To, czego powinieneś użyć, zależy od tego, co dokładnie chcesz zrobić? Jeśli możesz podać więcej szczegółów, możemy pomóc. Jeśli uruchamiasz wiele zapytań, funkcja db_query () jest najszybsza. Jeśli jednak ładujesz za pomocą encji (entity_load), prawdopodobnie nie ma to znaczenia, ponieważ ładowanie encji będzie powolne podczas ładowania ponad 1600 encji.

— donutdan4114

Jest w tym coś więcej niż tylko szybkość kodu zapytania / zapytania. Na przykład potrzebujesz dostępu do węzła?

— rooby

@rooby - Tak. Nadal korzystałem z EntityFieldQuery, ale na moje potrzeby muszę mieć dostęp do trzech niestandardowych pól w węzłach. Jednak poniższa odpowiedź jest nadal najlepszą odpowiedzią, ponieważ raf dał kilka całkiem dobrych rad i liczb. Właśnie tego szukałem.

— Jorge Calderon

Odpowiedzi:

Krótko mówiąc, aby odpowiedzieć na twoje pytanie, db_query jest najszybszy! Oto kilka powodów, faktów i liczb zebranych z różnych pytań, źródeł:

Proste wyszukiwanie w Google na to pytanie, wymyśl następujące wyniki:

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

i to

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

Jeśli zauważysz powyżej, db_select wykonuje więcej wywołań funkcji i wykorzystuje więcej pamięci niż db_query.

Zobacz tutaj powody, dla których warto używać db_select
Zobacz tutaj powody, dla których warto używać EntityFieldQuery zamiast db_select
Zobacz tutaj porównanie wydajności db_query i db_select

Myślę, że wybór powinien opierać się wyłącznie na twoich wymaganiach. EntityFieldQuery może być wolniejszy, ale oferuje wiele zalet, takich jak prosta składnia, pamięć w terenie jest podłączana, luźne sprzęganie i wiele innych.

— Raf
źródło

Właśnie tego szukałem. Wielkie dzięki, Raf.

— Jorge Calderon,

To bardzo zły pomysł, bo w przypadku 1600 węzłów nie należy obchodzić interfejsów API i używać EntityFieldQuery. Optymalizujesz niewłaściwą rzecz.

Cześć Chx, mógłbyś opracować. Podsumowując, należy wyciągnąć 1600 węzłów. Już używam EntityFieldQuery, więc po prostu próbuję zrozumieć, jaki byłby zły pomysł. Odkryłem, że EntityFieldQuery ogranicza się w niektórych obszarach. Jak dotąd nic mnie nie dotyczy. Tak czy inaczej, czekam na wysłuchanie twoich myśli.

— Jorge Calderon

Jeśli potrzebujesz tylko danych pól ze wszystkich 1600 węzłów, EFQE może być pomocne. Jeśli masz już EFQ, powinieneś być w stanie dowiedzieć się, czego potrzebujesz, patrząc na stronę piaskownicy.

— mikeytown2
źródło