Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Стоит добавить, что при оптимизации приложений в первую очередь стоит оптимизировать логику, а не js-конструкции.
Ну оно вроде как друг с другом связано )
Логика то в конечном итоге через конструкции и выражается.
Кроме того, некоторые решения могут быть очень логичными и правильными с точки зрения архитектуры, но не оптимальными с точки зрения производительности в конкретном узком месте. Тут уже как обычно надо искать «золотую середину».
Логика то в конечном итоге через конструкции и выражается.
Кроме того, некоторые решения могут быть очень логичными и правильными с точки зрения архитектуры, но не оптимальными с точки зрения производительности в конкретном узком месте. Тут уже как обычно надо искать «золотую середину».
Позволю не согласиться :)
В общем случае у вас не будет милионов и даже тысяч вызовов этих конструкций, получается что оптимизация конструкций — экономия на спичках.
В подавляющем большинстве случаев приложение тормозит из-за неправильных или неэффективных алгоритмов.
Поэтому под оптимизацией стоит понимать не поиск наиболее быстрого способа пробижаться по массиву из миллиона элементов, а поиска алгоритма, позволяющего избежать этого действия.
В общем случае у вас не будет милионов и даже тысяч вызовов этих конструкций, получается что оптимизация конструкций — экономия на спичках.
В подавляющем большинстве случаев приложение тормозит из-за неправильных или неэффективных алгоритмов.
Поэтому под оптимизацией стоит понимать не поиск наиболее быстрого способа пробижаться по массиву из миллиона элементов, а поиска алгоритма, позволяющего избежать этого действия.
Ну во первых, тысячи вызовов запросто могут быть. Иногда даже не замечаешь, как в одном методе вызывается другой, в нем третий, там еще обертка. В итоге вроде вызываешь метод 200 раз, а на самом деле тысяча-другая функций вызывается в это время.
Во-вторых, непонятно, что значит экономия на спичках.
Вот конкретно пара примеров — есть прямой цикл, есть обратный. Обратный в 2-3 раза быстрее. Да, разница в абсолютном показателе невысока, но зачем делать медленно если можно сделать быстро (при условии что порядок перебора не важен)? Инвертированный цикл даже короче в записи.
Еще пример — приватные и обычные свойства объекта. Некоторые любят понаделать приватных свойств, понаписать к нем геттеров (как привыкли в других языках), и потом копеечка к копеечке интерфейс может начать тормозить. Тесты наглядно показывают, чем это может грозить.
Во-вторых, непонятно, что значит экономия на спичках.
Вот конкретно пара примеров — есть прямой цикл, есть обратный. Обратный в 2-3 раза быстрее. Да, разница в абсолютном показателе невысока, но зачем делать медленно если можно сделать быстро (при условии что порядок перебора не важен)? Инвертированный цикл даже короче в записи.
Еще пример — приватные и обычные свойства объекта. Некоторые любят понаделать приватных свойств, понаписать к нем геттеров (как привыкли в других языках), и потом копеечка к копеечке интерфейс может начать тормозить. Тесты наглядно показывают, чем это может грозить.
Вы все правильно сказали: «разница в абсолютном показателе невысока».
Прирост в несколько миллисекунд — это и есть экономия на спичках.
Прирост в несколько миллисекунд — это и есть экономия на спичках.
Я там еще правильно сказал — зачем делать медленно, если можно делать быстро с теми же трудозатратами?
Вот вам если ДедМороз предложит совершенно бесплатно взять 10 000 рублей или 9 960, на выбор — вы что возьмете? Разница то вроде невелика.
Вот вам если ДедМороз предложит совершенно бесплатно взять 10 000 рублей или 9 960, на выбор — вы что возьмете? Разница то вроде невелика.
из-за того, что разница невелика, я возьму то, что удобнее положить в кошелек :)
или в случае програмимрования легче читается, понимается и поддерживается.
микрооптимизация, к сожалению, не приносит желаемых результатов. Конечно, не стоит совсем о ней забывать, и ваша статья хороша для понимания правильных конструкций. Но, как я уже говорил, в первую очередь надо искать узкие места в алгоритмах.
или в случае програмимрования легче читается, понимается и поддерживается.
микрооптимизация, к сожалению, не приносит желаемых результатов. Конечно, не стоит совсем о ней забывать, и ваша статья хороша для понимания правильных конструкций. Но, как я уже говорил, в первую очередь надо искать узкие места в алгоритмах.
Полностью согласен. Я выберу именно прямой цикл, потому как данная конструкция более привычна большинству программистов — молодой специалист не запутается в моем коде.
Полностью согласен. Я выберу именно прямой цикл, потому как данная конструкция более привычна большинству программистов — молодой специалист не запутается в моем коде.
есть полуюмористическая метрика качества кода по количеству «WTF?!» при его чтении
каждый обратный цикл будет порождать лишний WTF, потому что логикой кода никак не обоснован
проблемы, возникающие у программистов при работе с таким кодом, более серьезны, чем проблемы из-за замедления на сотую процента у пользователей
каждый обратный цикл будет порождать лишний WTF, потому что логикой кода никак не обоснован
проблемы, возникающие у программистов при работе с таким кодом, более серьезны, чем проблемы из-за замедления на сотую процента у пользователей
если порядок перебора массива не важен для текущей задачи, то с какой стати прямой перебор более логичен, чем обратный?
и что это за программист, у которого возникают проблемы, когда он видит обратный цикл?
и что это за программист, у которого возникают проблемы, когда он видит обратный цикл?
проблема: «почему здесь используется именно обратный проход по массиву, а не прямой? нужно искать причину»
прямой более логичен по той же причине, по которой вы помните алфавит, начиная с первой буквы, а не наоборот. Или я ошибся?; )
прямой более логичен по той же причине, по которой вы помните алфавит, начиная с первой буквы, а не наоборот. Или я ошибся?; )
Хм, алфавит говорите… Вот у вас в коробке лежат 33 вырезанные из картона буквы русского алфавита. Ваша задача — перекрасить их все в зеленый цвет, вытаскивая по одной.
Вы как будете буквы перекрашивать: в алфавитном порядке или просто в порядке доставания из коробки?
Да, согласен, какие-то нестандартные или даже просто немного непохожие на классику конструкции могут вызывать определенные сложности у некоторых людей, но это не повод не использовать их при написании скриптов. Потому что, повторюсь, нормального программиста нестандартные конструкции не испугают. А если их нестандартность оправдана, то еще и добавят ему в копилку немного опыта.
Вы как будете буквы перекрашивать: в алфавитном порядке или просто в порядке доставания из коробки?
Да, согласен, какие-то нестандартные или даже просто немного непохожие на классику конструкции могут вызывать определенные сложности у некоторых людей, но это не повод не использовать их при написании скриптов. Потому что, повторюсь, нормального программиста нестандартные конструкции не испугают. А если их нестандартность оправдана, то еще и добавят ему в копилку немного опыта.
нет, лежат они не в коробке, а выложены в линию по порядку. Очень сомневаюсь, что в этой ситуации вы начнёте красить справа или снизу
сложности — ещё какой повод! Ну если только вы не пишете перловые однострочники или другой write-only код. Про «нормального программиста» у вас очень субъективное мнение ; )
и вообще, пишите уже на Forth тогда ; )
ладно, не буду вас дальше переубеждать, мне с вами не работать, бесполезная трата слов получается
сложности — ещё какой повод! Ну если только вы не пишете перловые однострочники или другой write-only код. Про «нормального программиста» у вас очень субъективное мнение ; )
и вообще, пишите уже на Forth тогда ; )
ладно, не буду вас дальше переубеждать, мне с вами не работать, бесполезная трата слов получается
не всегда :) Например, если у нас есть цикл с регулярками, который выполняется, ну пусть, 100 раз, то тормозить будет заметно. Если же ту же самую логику записать с помощью хэшей или сравнений, то прирост производительности на лицо.
Ветви через hash функции впервые увидел, этакий мутант из обьекта с параметрами…
Иногда бывают такие штуки, что в switch их писать неудобно (по разным причинам, например код излишне дублируется или не хочется лишними переменными засорять текущий контекст). Тогда хэш может помочь. По сути, это такой полиморфизм на лету.
Можно вообще так писать:
({'one': obj.method, 'two': function(i) {return obj2.method3(i)*18}, 'three': function(){return false}})[value](i);
Хотя не факт что нужно )
Можно вообще так писать:
({'one': obj.method, 'two': function(i) {return obj2.method3(i)*18}, 'three': function(){return false}})[value](i);
Хотя не факт что нужно )
Для меня, пишущего на c#, выглядит ужасно =)
Хотя понятно конечно что hash в редких случаех удобнее, в нём нельзя например как в switch указать
case 21:
case 22:
case 23: doSomething(); break;
и нету замены для default
но нельзя не согласиться что иногда это может быть удобно.
Хотя понятно конечно что hash в редких случаех удобнее, в нём нельзя например как в switch указать
case 21:
case 22:
case 23: doSomething(); break;
и нету замены для default
но нельзя не согласиться что иногда это может быть удобно.
switch (..) {
case 21:
case 22:
case 23: doSomething(); break;
}
hash[21] = hash[22] = hash[23] = function(){ doSomething(); }
switch (..) {
case 21: doSomething1();
case 22: doSomething2();
case 23: doSomething3(); break;
}
hash[21] = function(){ doSomething1(); };
hash[22] = function(){ hash[21](); doSomething2(); };
hash[23] = function(){ hash[22](); doSomething3(); };
это что за цифры? количество секунд, миллисекунд, минут, часов, загрузка процессора?
Хорошо было бы указать единицы измерения. Без них результаты ни о чем не говорят. Всегда
Хорошо было бы указать единицы измерения. Без них результаты ни о чем не говорят. Всегда
Как мне видится, лучшая оптимизация — это поиск повторяющихся мест и создание единой функции для выполнения часто повторяющихся действий (или же обьёмных по коду), это позволяет разделить код на отдельные части которые станет визуально проще анализировать.
Например код сравнения двух массивов:
пока что для себя я нашёл такой способ наиболее оптимальный, но для небольших массивов.
Предполагаю что с увиличением массива такой метод будет требовать больше времени, причём в геометрической прогрессии…
Например код сравнения двух массивов:
Array.prototype.Equals = function(value) {
if (value.constructor != Array) return false;
if (this.length != value.length) return false;
var ar1 = new Array().concat(this);
var ar2 = new Array().concat(value);
var result = ar1.sort().toString() == ar2.sort().toString();
delete ar1;
delete ar2;
return result;
}
* This source code was highlighted with Source Code Highlighter.пока что для себя я нашёл такой способ наиболее оптимальный, но для небольших массивов.
Предполагаю что с увиличением массива такой метод будет требовать больше времени, причём в геометрической прогрессии…
Немного непонятна логика метода Equals, тот момент где сортировка происходит.
Даже если массивы имеют одинаковый набор элементов, но разный их порядок — называть их эквивалентными как-то неправильно по-моему.
А по существу — если не делать сортировку, то
в десятки (в некоторых случаях в сотни) раз быстрее, жрет меньше памяти и меньше места в коде.
Даже если массивы имеют одинаковый набор элементов, но разный их порядок — называть их эквивалентными как-то неправильно по-моему.
А по существу — если не делать сортировку, то
Array.prototype.Equals = function(value) {
if (value.constructor != Array) return false;
if (this.length != value.length) return false;
for(var i=this.length; i--;) {
if(this[i]!==value[i]) return false;
}
return true;
}
* This source code was highlighted with Source Code Highlighter.в десятки (в некоторых случаях в сотни) раз быстрее, жрет меньше памяти и меньше места в коде.
создание единой функции...Тут важно, чтобы не захотелось сделать тоже самое с прототипом Object: из-за этого желания проход по всем свойствам объекта уже нельзя будет сделать простым for (i in Obj) {… }, что повлечёт за собой дополнительные затраты ресурсов (как минимум на hasOwnProperty)
Чего-то я только сейчас подумал, если сравнить две коллекции используя ===
именно 3 равно, что сравнивает не только тип, но и value.
Подозреваю конечно что ничего не даст, но как доберусь до лома, обязательно проверю…
именно 3 равно, что сравнивает не только тип, но и value.
Подозреваю конечно что ничего не даст, но как доберусь до лома, обязательно проверю…
Не даст ничего потому, что array — это объект, а с объектами работа только по ссылке. Таким образом получить true можно только сравнивая массив сам с собой, либо две ссылки на один и тот же массив.
ar=[];
ar2=ar;
alert(ar==ar2); //true
И даже точного сравнения не надо.
ar=[];
ar2=ar;
alert(ar==ar2); //true
И даже точного сравнения не надо.
> используя === именно 3 равно, что сравнивает не только тип, но и value.
наоборот (вероятно, опечатка) — что сравнивает не только value, но и тип
наоборот (вероятно, опечатка) — что сравнивает не только value, но и тип
> var ar1… delete ar1;
var'ы, созданные не через eval, удалить нельзя (они все получают внутреннее свойство {DontDelete})
var'ы, созданные не через eval, удалить нельзя (они все получают внутреннее свойство {DontDelete})
А можно заголовки с названиями браузеров во все таблицы добавить?
В 3 и 4 запутался где какой браузер.
В 3 и 4 запутался где какой браузер.
при тестировании ветвления к какой из ветвей вы получали доступ? случайной, фиксированной или последовательно ко всем?
если не трудно, можете сделать тест для переменного числа ветвей (от 1 до 10, например)?
если не трудно, можете сделать тест для переменного числа ветвей (от 1 до 10, например)?
Там все просто было, брался шаг цикла (от нуля до миллиона соответственно) и делился с остатком на число ветвей (a=i%8, где a — условие ветви, i — шаг цикла, 8 — кол-во ветвей).
Таким образом можно получить равномерное распределение по всем ветвям.
Соответственно, в каждом из тестов и на каждом прогоне ветви вызывались в одном и том же порядке и пропорциях.
Таким образом можно получить равномерное распределение по всем ветвям.
Соответственно, в каждом из тестов и на каждом прогоне ветви вызывались в одном и том же порядке и пропорциях.
сделать тест для переменного числа ветвей (от 1 до 10, например)
Да по-моему не имеет смысла.
Для 1-2 ветвей вообще проще всего использовать тернарный оператор, как вот ниже в комментах написали.
Для большего кол-ва ветвей интуитивно понятно, что switch будет работать быстрее чем множественные if else, к тому же предоставлять больше возможностей. Причем чем больше ветвей, тем больше разница во времени выполнения.
Да по-моему не имеет смысла.
Для 1-2 ветвей вообще проще всего использовать тернарный оператор, как вот ниже в комментах написали.
Для большего кол-ва ветвей интуитивно понятно, что switch будет работать быстрее чем множественные if else, к тому же предоставлять больше возможностей. Причем чем больше ветвей, тем больше разница во времени выполнения.
Ещё бы исходнички, я бы на Опере 10 потестил
Да там нету как таковых исходников. Я сначала хотел все по правильному сделать, для каждого теста свою функцию и ее вызывать в цикле, но после того как увидел, сколько функция сама по себе выполняется…
В итоге пришлось для каждого нового теста комментить старый код внутри тела цикла и писать новый.
В итоге пришлось для каждого нового теста комментить старый код внутри тела цикла и писать новый.
Вот, если хотите, по самим циклам тесты (те, которые первые в статье):
var loop=1000000;
function start() {time=new Date();}
function end() {document.write("
"+(new Date() - time));}
var cicles={
'classic_cicle': function(){for(var i=0; i<loop; i++) {}},
'invert_cicle': function(){for(var i=loop; i--;) {}},
'while_cicle': function() {var i=loop; while(i--) {}}
}
start();
cicles.classic_cicle();
end();
1000000 записей… ммм я не часто такое количество обьектов вижу =) а темболее в виде хеша
может я ошибаюсь, но это не совсем корректный способ тестирования скорости
может я ошибаюсь, но это не совсем корректный способ тестирования скорости
> он обычно колеблется в пределах +-2-5% в зависимости от текущей загрузки системы
А загрузка системы разве не должна быть нулевая во время тестирования?
А загрузка системы разве не должна быть нулевая во время тестирования?
Ну я естественно не запускал никаких тяжелых приложений во время тестов (собственно, вообще все закрыл кроме браузеров), но винда периодически может выполнять какие-то свои внутренние задачи, которые жрут немножко процессорного времени.
Для этого каждый тест в одном браузере и прогоняется несколько раз, чтобы понять среднее значение.
Для этого каждый тест в одном браузере и прогоняется несколько раз, чтобы понять среднее значение.
Хорошая статья. Но надо понимать, что помимо производительности самого джаваскрипта, следует также учитывать (даже в большей степени) общую производительность веб-браузеров — этот вопрос хорошо осветил Сергей Чикуенок в статье «Производительность браузеров в зависимости от верстки».
Вот тут хорошая подборка тестов
www.rockstarapps.com/samples/performance/
www.rockstarapps.com/samples/performance/
P.S. я как раз собирался писать серию статей по следам оптимизации YASS, но меня опередили немного :)
Вообще говоря, быстрее хэша будет обычное сравнение, т.е.
Вообще говоря, быстрее хэша будет обычное сравнение, т.е.
a ? b = 6+2 : b = 8*3
Меня кстати вот этот твой комментарий и натолкнул на мысль о статье.
Так что все взаимосвязано )
Так что все взаимосвязано )
Ну протестируйте еще что быстрее
if (my == 'раз' || my == 'два' || my == 'три')…
или
if ({'раз',1;'два':1,'три':1}[my])…
еще я замечал
my = myArray.shift();
работает медленнее чем
myArray.reverse(); my = myArray[myArray.length-1]; myArray.length--; myArray.reverse();
вот это действительно странно, в отличии от того почему myArray.push(my) медленнее myArray[myArray.length]=my
Чтобы вызвать метод объекта нужно больше «Ку» сделать чем прочитать и записать его свойство
if (my == 'раз' || my == 'два' || my == 'три')…
или
if ({'раз',1;'два':1,'три':1}[my])…
еще я замечал
my = myArray.shift();
работает медленнее чем
myArray.reverse(); my = myArray[myArray.length-1]; myArray.length--; myArray.reverse();
вот это действительно странно, в отличии от того почему myArray.push(my) медленнее myArray[myArray.length]=my
Чтобы вызвать метод объекта нужно больше «Ку» сделать чем прочитать и записать его свойство
Почитаю в Хабрадайжесте))
На самом деле чистого яваскрипта в веб приложениях мало. Никто ж не делает на нем числомолотилки. Поэтому такие синтетические тесты это вещь в себе. Тесты ради тестов. Ну и что, что реализация яваскрипта в Хром быстрее всех. Реальные веб приложения от этого выигрыша практически не имеют. Что-то незаметно что страницы летают во столько же раз быстрее во сколько быстрее яваскрипт в тестах. А в некоторых тестах он даже и медленнее чем IE.
Имхо основные тормоза возникают при работе с браузерными объектами — обращение к атрибутам и свойствам узлов и их изменение, создание/удаление узлов DOM, изменения innerHTML(при этом браузер чистит/меняет дерево DOM ). Работа с XML. Работа со стилями. Обработка событий. Вот где зарыты узкие места, а не в скорости интерпретации яваскрипта.
Имхо основные тормоза возникают при работе с браузерными объектами — обращение к атрибутам и свойствам узлов и их изменение, создание/удаление узлов DOM, изменения innerHTML(при этом браузер чистит/меняет дерево DOM ). Работа с XML. Работа со стилями. Обработка событий. Вот где зарыты узкие места, а не в скорости интерпретации яваскрипта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Производительность простых и сложных конструкций в JavaScript