Реактивный JS
Прошу простить за многообещающее название.
Решил для новичков разместить несколько всем хорошо известных
примеров быстрой работы тривиальных задач.
Структура примеров следующая:
Одна и также задача решается двумя способами.
первый пример медленная работа, второй быстрая.
var a= [];
for(var i=0;i<100000;i++){
a[i]=(function(i){
return function(){
;
};
})(i)
}
var t1 = +new Date();
for(var i=0;i<100000;i++){
if(a[i]==90000){
break;
}
}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
var o = {};
for(var i=0;i<100000;i++){
o[i] = (function(i){
return function(){
;
};
})(i);
}
var t1 = +new Date();
o[90000]();
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
Для наглядности
var users = [{
login:'login_1',
sid:1,
params:[]
},{
login:'login_2',
sid:2,
params:[]
}];
for(var i=3;i<100000;i++){
users.push({
login:'login_'+i,
sid:i,
params:[]
});
}
var t1 = +new Date();
for(var i=0;i<100000;i++){
if(users[i].login=='login_90000'){
break;
}
}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
var users = {login_1:{
sid:1,
params:[]
},login_2:{
sid:2,
params:[]
}};
for(var i=3;i<100000;i++){
users['login_'+i] = {
sid:i,
params:[]
};
}
var t1 = +new Date();
if(!!users['login_90000']){}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
var t1 = +new Date();
for(var i=0;i<100000;i++){}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
var t1 = +new Date();
var i=0;
while(i++<100000){}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
var t1 = +new Date();
var i=100000;
while(--i){}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
EcmaScript 5
var arr = new Array(100000);
var t1 = +new Date();
arr.forEach(function(v){});
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
if else или switch
var a = 10,
t1 = +new Date();
for(var i=0;i<100000;i++){
if(a==1){}
else if(a==2){}
else if(a==3){}
else if(a==4){}
else if(a==5){}
else if(a==6){}
else if(a==7){}
else if(a==8){}
else if(a==9){}
else if(a==10){}
}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
var a = 10,
t1 = +new Date();
for(var i=0;i<100000;i++){
switch(a){
case 1:break;
case 2:break;
case 3:break;
case 4:break;
case 5:break;
case 6:break;
case 7:break;
case 8:break;
case 9:break;
case 10:break;
}
}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
if else или switch
var a = 2,
t1 = +new Date();
for(var i=0;i<100000;i++){
if(a==1){}
else if(a==2){}
else{}
}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
var a = 10,
t1 = +new Date();
for(var i=0;i<100000;i++){
switch(a){
case 1:break;
case 2:break;
default:;
}
}
var t2 = +new Date();
alert(t2-t1+" миллисекунд");
|
Во второй задаче в while нолик пропущен.
Ну и собственно о чем первая задача? Последовательный перебор массива всяко медленнее прямого обращения к элементу.
>Во второй задаче в while нолик пропущен.
Поправил.
>Ну и собственно о чем первая задача? Последовательный перебор массива всяко >медленнее прямого обращения к элементу.
Всем понятно, а только всё равно не ищут так, а делают перебор.
Смысл в том, чтобы не делать поиск по массиву инфы, а перейти на хэш-таблицы или для простоты объекты с парой ключ->значение.
Предвзятые тесты. Цикл for можно ускорить. Что это ты логику while оптимизировал, а у for забыл? Результат будет быстрее, чем while. Логические структуры так же не объективны. Для начала, почему сравнение не строгое? Ведь switch проводит строгое сравнение, а оно само по себе быстрее. Почему только один тип для сравнения? И почему конструкции пустые? Про оптимизацию пустых конструкций слышал? В первом шаге тоже никакого смысла не увидел. Для новичков говоришь разместил? Тогда не вводи их в заблуждение.
>Цикл можно ускорить
Вот этот for(var i=0;i<100000;i++){}?
И как?
>Что это ты логику while оптимизировал, а у for забыл
И где у for можно оптимизировать логику
for(var i=0;i<100000;i++){} ?
>Для начала, почему сравнение не строгое? Ведь switch проводит строгое >сравнение, а оно само по себе быстрее
=== дает тот же результат
>И почему конструкции пустые?
Потому, что дело не в них.
В обоих примерах констурукции пустые.
> В первом шаге тоже никакого смысла не увидел
Вы просто не пользуетесь фишкой хэш-таблиц.
Видимо не поняли.
>Для новичков говоришь разместил? Тогда не вводи их в заблуждение.
Эти примеры взяты не с потолка.
Прочти книгу
http://oreilly.com/catalog/9780596802806
Если есть с чем поспорить приводи реальные примеры и я с тобой соглашусь.
Советую еще раз внимательно посмотреть код.
Где стоят замерители времени и скорость какого участка кода тестируется.
А вообще, от браузера к браузеру значения варьируются и настолько незначительно, что об оптимизации этих процессов за частую и думать не нужно. Оптимизировать стоит только ресурсозатратные участки кода или то, где разница во времени обработки значительна. Например тонкости перебора циклами коллекций или что быстрее .test или .indexOf для некоторых проверок. И тому подобное...
Ок, ускоряем и уменьшаем.
for(var i=0; i++<100000;)
Еще быстрее?
for(var i=100000; i--;)
Уже давно известно, что строгое сравнение с известным типом выполняется быстрее. В интернете по этому поводу много информации, при желании :-)
Тесты никто не собирает пустыми конструкциями. Думаешь просто так? Не поленись проверить в нескольких браузерах.
Вообще, книги читать - это хорошо, для самой читающей нации. Жаль они имеют свойство быстро устаревать. Я доверяю объективным тестам и не авторам книг, а например авторам фрейм-ворков, таким, как Резиг и самому себе. Если хоть раз листал исходники, к примеру jQuery, то мог наблюдать по настоящему быстрые циклы и строгие сравнения. Зачем нужно лишнее равно, там где можно обойтись не строгим сравнением? Зачем лишний байт, ведь сравнении множество в этой библиотеке и объем растет. Ответ прост - это быстрее... Вообще в интернете множество объективных тестов. Полистай на досуге :-) Это и есть реальные и жизненные примеры а не единичные мнения авторов книг )) Всё же коллективный разум...
Со всем уважением к Рейсигу, но код JQuery ужасен, в стравнении с Mootools, Ext и пр. Причем он сам это не отрицает, и планирует его переписать с нуля на текущем месте работы.
Про циклы, безусловно обратный цикл всегда быстрей, но как показывают тесты for уступает while в производительности даже с учетом оптимизации, но оказывается более наглядней и порой компактней. Однако в реальных условиях ms не столь важны как секунды))
А можно уточнить про ужасный код?
Это о читаемости кода или о его функциональности?
Если о функциональности, можно пример функции, которая работает хуже, чем её аналог в mootools? Я слышал море критики в сторону кода mootools, но по поводу качества работы jQuery еще не встречал.
Ну а если речь о читаемости, то тут уже на вкус и цвет все фломастеры разные. Кому какой стиль написания нравится.
И еще, там где нужна конструкция if...else... обычно достаточно сделать a ? b : c.
С твоим примером, объективней было бы сделать примерно следующее:
Не правда ли больше похоже на switch? И гораздо компактнее обоих способов :-) Еще лучше вместо цифр испытать строки, они показывают лучшую скорость при строгом сравнении.
...
А пример реального приложения, ускоренного такими оптимизациями (первое не в счет - она число алгоритмическая) можно? Сколько вижу советы использовать ++i или i+=1 вместо i++ или === вместо ==, все никак не пойму - зачем это? Оно никогда не станет узким местом, так какой смысл это оптимизировать? Преждевременная оптимизация, как известно, зло.
Ну или покажите мне пример реального приложения, которое после применения оптимизаций стало работать быстрее (причем существенно быстрее, так, чтобы было заметно даже юзеру).
Не всегда преждевременная оптимизация является таковой.
Мне лично цикл for не нравится, ну не люблю я его и если есть возможность его заменить на while без существенного ущерба наглядности и производительности, то я это сделаю, потому что мне так удобно.
А на счет преф/постфиксного ин/декремента, тут нужно смотеть по ситуации, а не по предпочтениям.
Однако, еще раз повтороюсь, если требуется перебрать NodeList из трех элементов, то вообще не разницы на сколько макросекунд тот или иной цикл выполнится...
Ну так когда что-либо из описанного выше оправдано еще на момент написания кода? Под "оправдано" я понимаю существенный прирост в производительности.
Вот кеширование length, например, я считаю оправданным, т.к. нам может попасться какая-нибудь живая коллекция и перебирать ее мы будем долго (а если мы еще будем сложным образом с ней работать, то использование некешированного length - это уже способ прострелить себе ногу).
Ну иногда стоит задумываться над мс, например в mousemove событии. Даже несколько выигранных мс могут заметно добавить плавности, особенно на слабых машинах. Другими словами эти знания могут понадобится там, где есть итерации. Хотя эти примеры и не показывают особых показателей, знать их 'для общего' развития не плохо.
Это да. Но в переборе коллекции всё же приятнее для глаза и быстрее наверное while, без единого запроса length.
while(node=collection[i++]){}лень запускать тесты и любоваться алертами..
попробуй вот эту штуку: http://nin-jin.github.com/web-components/lib_dev/lib_dev/lib_dev.doc.xml
.ня
Это что ваше за жесть в первом примере лишь тупой идиот может использовать подобное
Strony typu roksa pl
Отправить комментарий
Приветствуются комментарии:- Полезные.
- Дополняющие прочитанное.
- Вопросы по прочитанному. Именно по прочитанному, чтобы ответ на него помог другим разобраться в предмете статьи. Другие вопросы могут быть удалены.
P.S. Лучшее "спасибо" - не комментарий, как все здорово, а рекомендация или ссылка на статью.Для остальных вопросов и обсуждений есть форум.