post increment vs pre increment-оптимизация Javascript
Я просматривал код Google, когда случайно наткнулся на этот проект под названием jspeed-optimization для Javascript.
Я заметил, что одна из оптимизаций заключалась в изменении i++ to ++i in для операторов цикла.
До Оптимизации
for (i=0;i<1;i++) {}
for (var i = 0, j = 0; i < 1000000; i++, j++) {
if (i == 4) {
var tmp = i / 2;
}
if ((i % 2) == 0) {
var tmp = i / 2;
i++;
}
}
var arr = new Array(1000000);
for (i = 0; i < arr.length; i++) {}
после оптимизации
for(var i=0;i<1;++i){}
for(var i=0,j=0;i<1000000;++i,++j){if(i==4){var tmp=i>>1;}
if((i&1)==0){var tmp=i>>1;i++;}}
var arr=new Array(1000000);for(var i=0,arr_len=arr.length;i<arr_len;++i){}
Я знаю, что делают приращения pre и post, но любая идея, как это ускоряет код?
8 ответов
вот что я прочитал и мог бы ответить на ваш вопрос: "preincrement (++i) добавляет один к значению i, затем возвращает i; напротив, i++ возвращает i затем добавляет к этому, что в теории приводит к созданию временной переменной, хранящей значение i перед применением операции приращения".
это искусственная оптимизация. Насколько я понимаю, вы сохраняете 1 код операции. Если вы хотите оптимизировать свой код с помощью этой техники, то вы пошли неправильным путем. Кроме того, большинство компиляторов / интерпретаторов оптимизируют это для вас в любом случае (ссылка 1). Короче говоря, я бы не беспокоился. но, если вы действительно обеспокоены, вы должны использовать i+=1.
вот быстрый и грязный тест, я просто сделал
var MAX = 1000000, t=0,i=0;
t = (new Date()).getTime();
for ( i=0; i<MAX;i++ ) {}
t = (new Date()).getTime() - t;
console.log(t);
t = (new Date()).getTime();
for ( i=0; i<MAX;++i ) {}
t = (new Date()).getTime() - t;
console.log(t);
t = (new Date()).getTime();
for ( i=0; i<MAX;i+=1 ) {}
t = (new Date()).getTime() - t;
console.log(t);
результаты непереработанными
Post Pre +=
1071 1073 1060
1065 1048 1051
1070 1065 1060
1090 1070 1060
1070 1063 1068
1066 1060 1064
1053 1063 1054
удалены низший и высший
Post Pre +=
1071 ---- 1060
1065 ---- ----
1070 1065 1060
---- 1070 1060
1070 1063 ----
1066 1060 1064
---- 1063 1054
средние
1068.4 1064.2 1059.6
обратите внимание, что это за один миллион итераций и результаты в пределах 9 МС в среднем. Не очень большая оптимизация, учитывая, что большая часть итеративной обработки в JavaScript выполняется над гораздо меньшими наборами (контейнеры DOM для образец.)
звучит как преждевременная оптимизация. Когда вы почти закончите свое приложение, проверьте, где узкие места и оптимизируйте их по мере необходимости. Но если вам нужно подробное руководство по производительности цикла, проверьте это:
http://blogs.oracle.com/greimer/entry/best_way_to_code_a
но вы никогда не знаете, когда это станет устаревшим из-за улучшений двигателя JS и изменений между браузерами. Лучший выбор-не беспокоиться об этом, пока это не проблема. Сделать код читаемым.
Edit: согласно этот парень пред и пост статистически незначимо. (с pre, возможно, хуже)
теоретически, используя оператор постинкремента мая произвести временное. На практике компиляторы JavaScript достаточно умны, чтобы избежать этого, особенно в таком тривиальном случае.
например, давайте рассмотрим этот пример кода:
sh$ cat test.js
function preInc(){
for(i=0; i < 10; ++i)
console.log(i);
}
function postInc(){
for(i=0; i < 10; i++)
console.log(i);
}
// force lazy compilation
preInc();
postInc();
в этом случае компилятор V8 в NodeJS производит ровно тот же байт-код (посмотрите esp. на опкодах 39-44 для инкремента):
sh$ node --version
v8.9.4
sh$ node --print-bytecode test.js | sed -nEe '/(pre|post)Inc/,/^\[/p'
[generating bytecode for function: preInc]
Parameter count 1
Frame size 24
77 E> 0x1d4ea44cdad6 @ 0 : 91 StackCheck
87 S> 0x1d4ea44cdad7 @ 1 : 02 LdaZero
88 E> 0x1d4ea44cdad8 @ 2 : 0c 00 03 StaGlobalSloppy [0], [3]
94 S> 0x1d4ea44cdadb @ 5 : 0a 00 05 LdaGlobal [0], [5]
0x1d4ea44cdade @ 8 : 1e fa Star r0
0x1d4ea44cdae0 @ 10 : 03 0a LdaSmi [10]
94 E> 0x1d4ea44cdae2 @ 12 : 5b fa 07 TestLessThan r0, [7]
0x1d4ea44cdae5 @ 15 : 86 23 JumpIfFalse [35] (0x1d4ea44cdb08 @ 50)
83 E> 0x1d4ea44cdae7 @ 17 : 91 StackCheck
109 S> 0x1d4ea44cdae8 @ 18 : 0a 01 0d LdaGlobal [1], [13]
0x1d4ea44cdaeb @ 21 : 1e f9 Star r1
117 E> 0x1d4ea44cdaed @ 23 : 20 f9 02 0f LdaNamedProperty r1, [2], [15]
0x1d4ea44cdaf1 @ 27 : 1e fa Star r0
121 E> 0x1d4ea44cdaf3 @ 29 : 0a 00 05 LdaGlobal [0], [5]
0x1d4ea44cdaf6 @ 32 : 1e f8 Star r2
117 E> 0x1d4ea44cdaf8 @ 34 : 4c fa f9 f8 0b CallProperty1 r0, r1, r2, [11]
102 S> 0x1d4ea44cdafd @ 39 : 0a 00 05 LdaGlobal [0], [5]
0x1d4ea44cdb00 @ 42 : 41 0a Inc [10]
102 E> 0x1d4ea44cdb02 @ 44 : 0c 00 08 StaGlobalSloppy [0], [8]
0x1d4ea44cdb05 @ 47 : 77 2a 00 JumpLoop [42], [0] (0x1d4ea44cdadb @ 5)
0x1d4ea44cdb08 @ 50 : 04 LdaUndefined
125 S> 0x1d4ea44cdb09 @ 51 : 95 Return
Constant pool (size = 3)
Handler Table (size = 16)
[generating bytecode for function: get]
[generating bytecode for function: postInc]
Parameter count 1
Frame size 24
144 E> 0x1d4ea44d821e @ 0 : 91 StackCheck
154 S> 0x1d4ea44d821f @ 1 : 02 LdaZero
155 E> 0x1d4ea44d8220 @ 2 : 0c 00 03 StaGlobalSloppy [0], [3]
161 S> 0x1d4ea44d8223 @ 5 : 0a 00 05 LdaGlobal [0], [5]
0x1d4ea44d8226 @ 8 : 1e fa Star r0
0x1d4ea44d8228 @ 10 : 03 0a LdaSmi [10]
161 E> 0x1d4ea44d822a @ 12 : 5b fa 07 TestLessThan r0, [7]
0x1d4ea44d822d @ 15 : 86 23 JumpIfFalse [35] (0x1d4ea44d8250 @ 50)
150 E> 0x1d4ea44d822f @ 17 : 91 StackCheck
176 S> 0x1d4ea44d8230 @ 18 : 0a 01 0d LdaGlobal [1], [13]
0x1d4ea44d8233 @ 21 : 1e f9 Star r1
184 E> 0x1d4ea44d8235 @ 23 : 20 f9 02 0f LdaNamedProperty r1, [2], [15]
0x1d4ea44d8239 @ 27 : 1e fa Star r0
188 E> 0x1d4ea44d823b @ 29 : 0a 00 05 LdaGlobal [0], [5]
0x1d4ea44d823e @ 32 : 1e f8 Star r2
184 E> 0x1d4ea44d8240 @ 34 : 4c fa f9 f8 0b CallProperty1 r0, r1, r2, [11]
168 S> 0x1d4ea44d8245 @ 39 : 0a 00 05 LdaGlobal [0], [5]
0x1d4ea44d8248 @ 42 : 41 0a Inc [10]
168 E> 0x1d4ea44d824a @ 44 : 0c 00 08 StaGlobalSloppy [0], [8]
0x1d4ea44d824d @ 47 : 77 2a 00 JumpLoop [42], [0] (0x1d4ea44d8223 @ 5)
0x1d4ea44d8250 @ 50 : 04 LdaUndefined
192 S> 0x1d4ea44d8251 @ 51 : 95 Return
Constant pool (size = 3)
Handler Table (size = 16)
конечно, другой JavaScript компиляторы/интерпретаторы мая поступить иначе, но это сомнительно.
в качестве последнего слова, для чего это стоит, я тем не менее считаю лучшей практикой использовать pre-increment, когда это возможно: поскольку я часто переключаю языки, я предпочитаю использовать синтаксис с правильным семантический для того, что я хочу, вместо того, чтобы полагаться на умность компилятора. Например, современные компиляторы C также не будут иметь никакого значения. Но в C++ это может оказать значительное влияние на перегружен operator++.
оптимизация не является приращением до и после. Это использование побитовых операторов "shift" и "and", а не divide и mod.
существует также оптимизация минимизации javascript для уменьшения общего размера (но это не оптимизация времени выполнения).
Это, вероятно, карго-культовое Программирование. Это не должно иметь значения, когда вы используете приличные компиляторы / интерпретаторы для языков, у которых нет произвольной перегрузки операторов.
эта оптимизация имеет смысл для C++, где
T x = ...;
++x
может изменить значение на месте, тогда как
T x = ...;
x++
создать копию, делая что-то под капотом, как
T x = ...;
T copy;
(copy = T(x), ++x, copy)
что может быть дорого для больших типов структур или для типы, которые делают много вычислений в своем конструкторе копирования.
тест Анатолия включал пост-инкремент внутри тестовой функции pre-increment: (
вот результаты без этого побочного эффекта...
function test_post() {
console.time('postIncrement');
var i = 1000000, x = 0;
do x++; while(i--);
console.timeEnd('postIncrement');
}
function test_pre() {
console.time('preIncrement');
var i = 1000000, x = 0;
do ++x; while(--i);
console.timeEnd('preIncrement');
}
test_post();
test_pre();
test_post();
test_pre();
test_post();
test_pre();
test_post();
test_pre();
выход
postIncrement: 3.21ms
preIncrement: 2.4ms
postIncrement: 3.03ms
preIncrement: 2.3ms
postIncrement: 2.53ms
preIncrement: 1.93ms
postIncrement: 2.54ms
preIncrement: 1.9ms
Это большая разница.
просто протестировал его в firebug и не нашел разницы между пост - и преинкрементами. Может быть, это оптимизация других платформ? Вот мой код для тестирования firebug:
function test_post() {
console.time('postIncrement');
var i = 1000000, x = 0;
do x++; while(i--);
console.timeEnd('postIncrement');
}
function test_pre() {
console.time('preIncrement');
var i = 1000000, x = 0;
do ++x; while(i--);
console.timeEnd('preIncrement');
}
test_post();
test_pre();
test_post();
test_pre();
test_post();
test_pre();
test_post();
test_pre();
вывод:
postIncrement: 140ms
preIncrement: 160ms
postIncrement: 136ms
preIncrement: 157ms
postIncrement: 148ms
preIncrement: 137ms
postIncrement: 136ms
preIncrement: 148ms