производительность jquery - .on по сравнению с onclick ()

Question

производительность jquery - .on по сравнению с onclick ()

0

Два основных вопроса, с которыми мне трудно найти ответы, следующие:

1) Эффективность привязки функции щелчка против ее запуска через onclick = "doness()", как в:

$("#id").find('a').on('click',function(){
    $(this).doingness();
});

против:

<div id="id"><a onlick="doingness()"></a></div>

function doingness(){
    $('#id').do();
}

Мне кажется, что второй может работать лучше всего, поскольку привязка не требуется, пока пользователь фактически не нажмет, поэтому скрипту не нужно искать всю DOM, чтобы найти идентификатор и связать что-то с ним. это правильно?

Затем я слышал, что использование этих (независимо от того, что это называется) очень дорогостоящее:

$('body').on('click', '#id', function(){
    $(this).do();
});

Конечно, я использую пару из них с динамически загруженным контентом, чтобы функции сохранялись в живых. Я предполагаю, что удар по производительности в основном связан со всей функцией, которая должна храниться в памяти, и, вероятно, снова и снова перерабатывается, чтобы проверить, не должно ли оно снова срабатывать или нет. Вместо этого кода я недавно понял, что вместо этого я могу просто добавить onclick = "doness()" в html, и мой вопрос в том, поможет ли эта работа?

user2777052 14 нояб. 2013, в 10:30

Источник

1

Вы пробовали бенчмаркинг с jsPerf или подобным?
Frédéric Hamidi 14 нояб. 2013, в 08:59
0

я бы даже здесь задавал вопрос, если бы все это сделал?
user2777052 14 нояб. 2013, в 09:14
1

Извините, но беспокоиться о производительности в этом случае просто смешно. Вы говорите о том, что происходит, когда пользователь нажимает на ссылку. Они не заметят никакой разницы, если задержка между щелчком и действием составляет 2 миллисекунды или 5 миллисекунд.
JJJ 14 нояб. 2013, в 09:14
0

Кто сказал, что я волновался?
user2777052 14 нояб. 2013, в 09:26

Показать ещё 2 комментария

Теги:

jquery

onclick

1 ответ

Ещё вопросы

Вы пробовали бенчмаркинг с jsPerf или подобным?
я бы даже здесь задавал вопрос, если бы все это сделал?
Извините, но беспокоиться о производительности в этом случае просто смешно. Вы говорите о том, что происходит, когда пользователь нажимает на ссылку. Они не заметят никакой разницы, если задержка между щелчком и действием составляет 2 миллисекунды или 5 миллисекунд.

Hans Roerdinkholder · Accepted Answer · 2013-11-14T06-31-00.000Z

Сравнивая подход 1 с подходом 2, встроенный "onclick" будет быстрее в том смысле, что DOM не нужно перемещать для поиска нужного узла (первый поиск по id, а затем по a-тегу внутри элемента с помощью Я бы). Но, честно говоря, я думаю, что дополнительная производительность (которая действительно не так важна, если, возможно, вы не пишете высокопроизводительные игры или нет) не перевешивает улучшения в разделении кода, предлагаемый первым подходом.

Ваш последний блок кода, на мой взгляд, - это то, что вам следует избегать. Эта форма встроенного метода с параметром селектора должна использоваться (imo), когда событие должно обрабатываться по целому ряду элементов (например, захват события click на каждом td в большой таблице). В этом случае это большое улучшение производительности, поскольку вам понадобится только один обработчик событий, а не, возможно, сотни или тысячи. Однако вы делаете это с помощью id-селектора, поэтому вы используете его только для одного элемента. Я понимаю добавленный бонус, что он будет работать, если элемент динамически вставлен, но вместо этого вы должны ждать с привязкой события до тех пор, пока элемент не вставлен, и не пойдете на обычный способ захвата события.

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