производительность селектора jQuery

Как насчет этого?

INSERT OR IGNORE INTO EVENTTYPE (EventTypeName) VALUES 'ANI Received'

(Непротестированный, поскольку у меня нет SQLite... однако , эта ссылка является довольно описательной.)

Кроме того, это должно также работать:

INSERT INTO EVENTTYPE (EventTypeName)
SELECT 'ANI Received'
WHERE NOT EXISTS (SELECT 1 FROM EVENTTYPE WHERE EventTypeName = 'ANI Received');

5
задан JonoW 11 September 2009 в 14:15
поделиться

6 ответов

Предполагая, что вы используете по крайней мере jQuery 1.3 (то есть с добавлением Sizzle), наблюдаемая производительность связана с изменением, при котором выполняется обход DOM. Из здесь :

До jQuery 1.2.6 включительно селектор двигателя работал в режиме «сверху вниз» (или «слева направо») способом. jQuery 1.3.x (то есть Sizzle , который встраивает jQuery) представил «снизу вверх» (или "справа налево") подход к запросам DOM.

Во втором примере ( "td.someColumnClass span.editMode input" ) Sizzle эффективно делает следующее:

  1. получает все входные элементы внутри someTableRow
  2. для каждого найденного входного элемента просмотрите его дерево предков для элементов диапазона с помощью class = "editMode" . Удалите элементы input , у которых нет этих предков
  3. , для каждого найденного элемента span.editMode , просмотрите его дерево предков для элементов td с помощью class = "someColumnClass" . Удалите элементы input , у которых нет этих предков

Однако в вашем первом примере вы явно определяете каждый шаг при каждом вызове find () , определение контекста и прохождение вниз оттуда. Вы применяете подход «сверху вниз». Это эквивалентно передаче контекста на каждом шаге, который обычно считается средством повышения производительности :

$('input', $('span.editMode', $('td.someColumnClass', someTableRow)))
14
ответ дан 18 December 2019 в 09:08
поделиться

Способ, которым JQuery обрабатывает селекторы, по моему опыту немного отличается от CSS.

Сокращение контекста для поиска - это ключ, как указал Джош.

Я нахожу использование двух селекторы параметров действительно быстрые

Как это сравнить по скорости?

Вам не нужны здесь все переменные, просто чтобы прояснить, что я делаю.

var columnClasses = $('.someColumnClass');
var tableCell = $('td', columnclasses);
var editMode = $('.editmode', tableCell);
var spanInside = $('span', editMode);
var inputFinally = $('input', spanInside);

Доброта,

Дэн

1
ответ дан 18 December 2019 в 09:08
поделиться

Because you are reducing the context for the search.

In case B, it has to search through every DOM element to see if it meets the criteria.

In case A, is can quickly decide to ignore anything that's not "td.someColumnClass", then it can take that subset of the DOM and ignore anything that's not in "span.editMode". So it has a much smaller set of elements to search through to find "input"s now.

2
ответ дан 18 December 2019 в 09:08
поделиться

A is more calls, but simpler. B is one call, but more complex. In this case, the complexity of the call greatly out-weighs the quantity of calls.

1
ответ дан 18 December 2019 в 09:08
поделиться

Здесь есть очень интересная статья о производительности селектора: http://blogs.atlassian.com/developer/2009/08/jquery_bondage.html

В ней автор показывает "привязку" расширения jQuery, которое показывает, сколько раз функция оценивается.

-1
ответ дан 18 December 2019 в 09:08
поделиться

Я сам провел небольшое исследование производительности jQuery Selector. Большая проблема - поиск по имени класса в Internet Explorer. IE не поддерживает getElementsByClassName - поэтому jQuery и другие фреймворки «повторно реализуют» его в JavaScript, перебирая все элементы DOM. Ознакомьтесь со следующим аналитическим блогом о производительности селектора jQuery

1
ответ дан 18 December 2019 в 09:08
поделиться
Другие вопросы по тегам:

Похожие вопросы: