отправьте инкремент по сравнению с пред инкремент - Оптимизация JavaScript
Люди в MigLayout имеют, устанавливают большую демонстрацию, которая позволяет Вам изучить, как настроить miglayout посредством экспериментирования.
Переходят в http://www.miglayout.com/ и выбирают Демонстрация Swing . Можно тогда видеть демонстрационное использование расположения и что еще более важно, можно щелкнуть правой кнопкой по любому компоненту (текстовое поле, маркировка, и т.д.) и изменить ограничения макета. Это - превосходный интерактивный инструмент для приобретения знаний о расположении и как оно будет работать с изменением размеров, и т.д.
5 ответов
Это то, что я прочитал и мог бы ответить на ваш вопрос: «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).
Только что протестировал его в 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
Sounds like premature optimization. When you're nearly done your app, check where the bottlenecks are and optimize those as needed. But if you want a thorough guide to loop performance, check this out:
http://blogs.oracle.com/greimer/entry/best_way_to_code_a
But you never know when this will become obsolete because of JS engine improvements and variations between browsers. Best choice is to not worry about it until it's a problem. Make your code clear to read.
Edit: According to this guy the pre vs. post is statistically insignificant. (with pre possibly being worse)
Оптимизация - это не приращение до и после. Это использование побитовых операторов «сдвиг» и «и», а не деление и изменение.