Что быстрее db_query, db_select или EntityFieldQuery

Поэтому я пытаюсь выяснить, что быстрее db_query, db_select или EntityFieldQuery. В настоящее время я использую EntityFieldQuery. Я собираю около 1600 записей узлов.

Я понимаю, что это может обременять систему, поэтому я просто хочу выяснить, какой вариант лучше всего захватить 1600 узлов. Бритье секунд или даже миллисекунд будет иметь большое значение для приложения, которое я создаю.

Заранее спасибо за ваши ответы.

database

— Хорхе Кальдерон
источник

Вы профилировали это?

— mpdonadio

Не уверен, что вы имеете в виду. Не могли бы вы уточнить немного?

— Хорхе Кальдерон

Что вы должны использовать, зависит от того, что вы пытаетесь сделать именно? Если вы можете дать более подробную информацию, мы могли бы помочь. Если вы выполняете много запросов, db_query () - самый быстрый. Однако, если вы загружаете сущности с ним (entity_load), это, вероятно, не имеет значения, потому что entity_load будет медленным при загрузке 1600+ сущностей.

— donutdan4114

Это больше, чем просто скорость кода запроса / запроса. Например, вам нужен доступ к узлу?

— Роби

@rooby - Да, я делаю. Я продолжал использовать EntityFieldQuery, но для своих нужд мне нужен доступ к трем настраиваемым полям в узлах. Тем не менее, ответ ниже по-прежнему является лучшим ответом, так как raf дал несколько довольно хороших советов и цифр. Что было именно то, что я искал.

— Хорхе Кальдерон

Ответы:

Если коротко ответить на ваш вопрос, db_query - самый быстрый! Вот некоторые причины, факты и цифры, составленные из разных вопросов, источников:

Простое гугление этого вопроса дает следующие результаты:

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

и это

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

Если вы заметили выше, db_select выполняет больше вызовов функций и использует больше памяти, чем db_query.

Смотрите здесь, чтобы узнать, почему использовать db_select.
Смотрите здесь, чтобы узнать, почему использовать EntityFieldQuery вместо db_select.
Смотрите здесь для сравнения производительности db_query и db_select

Я думаю, что выбор должен быть основан исключительно на ваших требованиях. EntityFieldQuery может быть медленнее, но предлагает много преимуществ, таких как простой синтаксис, возможность хранения полей с возможностью подключения, слабая связь и многие другие.

— Raf
источник

Это именно то, что я искал. Спасибо, Раф.

— Хорхе Кальдерон

Это очень плохая идея, для 1600 узлов не обходить API-интерфейсы и использовать EntityFieldQuery. Вы оптимизируете не ту вещь.

Привет Чх, не могли бы вы уточнить. Итак, суть в том, что нужно вытянуть 1600 узлов. Я уже использую EntityFieldQuery, поэтому просто пытаюсь понять, что это за плохая идея. Я обнаружил, что EntityFieldQuery ограничивает в некоторых областях. Пока это ничего не влияет на меня. В любом случае, жду ваших мыслей.

— Хорхе Кальдерон

Если вы просто хотите получить полевые данные со всех 1600 узлов, EFQE может быть полезен. Если у вас уже есть EFQ, вы сможете выяснить, что вам нужно, заглянув на страницу с песочницей.

— mikeytown2
источник