Comments 16
Иногда кажется, что легче пропустить проверку на «null» и просто перехватывать соответствующие исключения.
Иногда лучше пропустить проверку на null и просто перехватить исключение. Есть то, что мы ожидаем и то, чего мы не ожидаем в нормальной работе приложения. Если мы ожидаем null, например, пользователь не включил чекбокс или это значение по умолчанию, то естественно это не исключение.
А если в длинной цепочке вызовов закралась ошибка и вдруг пришел null вместо ID пользователя, хотя тут явно должен был быть ID? Это как раз исключение. Мы выкидываем исключение и ловим его там, где нам надо обработать его (залогировать, сообщить пользователю об этом, откатить транзакцию и т.п.).
Исключения в нормальной ситуации должны происходить довольно редко по отношению к другим событиям. Из-за этого выигрыш будет минимальным.
Можно и микроскопом забивать гвозди, но зачем?
По моему скромному мнению, высокая производительность фронта, частично зависит от грамотности подготовки данных на бекенде. И профилировать бекенд на жту тему гораздо эффективней зачастую. Зачем отдавать списки из тысяч элементов, если контекст уже говорит нам о том, что достаточно отдать 10..20 и уже среди них искать на фронте, хоть по id, хоть перебором.
Опять же, даже при вылизанном бекенде, во фронтенде «развернуться» можно о-го-го как. Так что весьма полезно знать, что же делать стоит, а что нет. Из памяти не выходит случай, когда на фронтенде по разным критериям самостоятельно сортировалась таблица идентификаторов за O(n**2). Данные при этом «кэшировались» в неотсортированом массиве. Сложность операции O(n**3) начинала достаточно быстро ощущаться при увеличении n. Вишенка на торте: в таблице могло оказаться больше элементов, чем допускал кэш.
Ещё нам часто приходится писать фронтенд, используя бекенд сторонних фирм, которые вообще никак не реагируют на просьбы оптимизировать его в конкретных местах. Так что нам остаётся ограничиваться только оптимизацией фронтенда, хотя мы и представляем себе, насколько удобнее и зачастую эффективнее профилировать бекенд.
document.getElementById('id');$('#id');
ну справедливости ради… скорость $('#id') всё равно достаточная, если это не миллион вызовов в цикле. Хотя, я, пожалуй, всё же откажусь от $('#id') хотя бы в циклах. Что-то и правда жесть.
логичнее сравнивать с querySelector.
а он всего вдвое быстрее
по поводу 1 200 000 000 операций в секунду… по своему опыту скажу, что когда это число сравнимо с частотой процессора, то с тестом что-то не так. я говорю не о банальном сложении двух чисел, а о вызове DOM функций, которые что-то ищут. например, getElementById может кэшировать результат последнего вызова. или шибко умный JIT может выкинуть что-то "лишнее". или, как отмечали выше, в DOM дереве всего два идентификатора и основное время занимает проверка параметров (перевод в строку и т.д.).
Проблема изучения производительности всех языков, кроме Java, что Алексей Шипилев делает доклады только по Java.
Один из основных посылов, в 99% случаев, когда люди, которые не занимаются профессионально производительностью, они не измеряют ничего.
В оставшееся проценте, даже при полном измерении, нельзя закладываться на особенности реализации кроме очень особых случаев, которые нужно все время отслеживать.
Например, то что сейчас обычный for() быстрее всех остальных вариантов, возможно только потому, что нет проемы с производительностью у других циклов в месте обычного использования, а завтра Google столкнется с какой-то задачей и жёстко оптимизирует все это в V8, как вариант.
Безусловно, здесь не учитывается преобразование данных, но даже с учетом его операция будет выполняться намного быстрее.
Безусловно тут только одно — тест без хотя бы создания объекта некорректный.
А предположить можно что угодно.
Но по тестам, на holyJs в свое время выходил доклад «Производительность JavaScript через подзорную трубу» Вячеслава Егорова. Там он разобрал ошибки тестов в js, как трудно их делать и лучше вообще не делать…
И мне кажется в этих тестах тоже кроется ошибка.
Как повысить производительность фронтенда веб-приложения: пять советов