Оптимизация: int vs uint, i+=1 vs i++ и т.д.

[Gaen]

А можно подробнее про вызов метода?

[WindWalker]

Вот на этих страничках можно почитать про исследование быстродействия различных арифметических операций.

http://www.rockonflash.com/blog/?p=63
http://osflash.org/as3_speed_optimizations

Было определено, что методы класса Math работают довольно медленно.
На самом деле дело не в том, что методы какие-то тормознутые, а в том, что вообще происходит вызов метода.

Например, вместо Math.abs(x) лучше использовать x<0?-x:x
Но если кто-то решит создать класс с быстрой математикой, например такой:

package {
    public class FastMath {
        public static function abs(x:Number):Number {
            return x<0?-x:x;
        }
   }
}

То абсолютно никакого выиграша не получит. А скорее всего даже наоборот будет проигрыш.
А всё дело в том, что сам вызов метода и возврат назад кушают больше, чем содержимое метода.

[Iv]

Сообщение от WindWalker

Тем не менее, для того, чтобы оптимизировать, необходимо знать как влияют на быстродействие те или иные операции.

- я, собственно, и пытаюсь донести то, что в данный момент здесь разговор идет о вещах столь незначительных для производительности, что говорить об этом не стоит вовсе.

[Gaen]

Iv, так давайте поговорим о действительно значительных для производительности вещах

[2morrowMan]

Вместо Math.floor можно спользовать: value >> 0;

Можно собрать список вот таких фич...

Post Update:

Протестил:

var time:Number = 0;
runFloorTest();
runFloorUintTest();
runFloorShiftTest();

function runFloorTest():void
{
    time = getTimer();
    for(var i:uint=0;i<10000000;i++)
    {
        var n:Number = 1.5;
        var test:Number = Math.floor(n);
    }
    trace("FloorTest: ", (getTimer()-time));
}

function runFloorUintTest():void
{
    time = getTimer();
    for(var i:uint=0;i<10000000;i++)
    {
        var n:Number = 1.5;
        var test:Number = uint(n);
    }
    trace("FloorUintTest: ", (getTimer()-time));
}

function runFloorShiftTest():void
{
    time = getTimer();
    for(var i:uint=0;i<10000000;i++)
    {
        var n:Number = 1.5;
        var test:Number = n >> 0;
    }
    trace("FloorShiftTest: ", (getTimer()-time));
}

Результат:
FloorTest: 2046
FloorUintTest: 392
FloorShiftTest: 280

[WindWalker]

Сообщение от Iv

- я, собственно, и пытаюсь донести то, что в данный момент здесь разговор идет о вещах столь незначительных для производительности, что говорить об этом не стоит вовсе.

Во-первых, говорить стоит обо всём. Хотя бы просто для общего развития, и чтобы понимать некоторые тонкости внутренней механики.

Во-вторых, если в цикле идёт голая математика, а сам цикл достаточно длинный, то даже такие мелочи начинают иметь значение.

В-третьих, иногда методы всё же вызываются, хотя мы этого и не предполагали. Вот, например, в чём разница между

var a:int = int(n);

и

var a:int = n;

где n имеет тип Number?

Разница в том, что в первом случае происходит вызов метода. Правда, что удивительно, на быстродействии это никак не сказывается.
Так что в AVM2 всё очень даже неоднозначно.

[Iv]

Сообщение от GAIKER

Iv, так давайте поговорим о действительно значительных для производительности вещах

- я бы сказал читабельность и простота кода. Следование стандартам написания кода. Правильное и значимое именование. Отказ от хаков.
Знание и правильное применение хорошей практики, в частности, шаблонов проектирования.
Как итог - понятный и логичный код без ошибок и лишних операций.

Оптимизация кода - только как отдельный, завершающий и четко направленный на узкие места процесс, при наличии тестов.
Прекращение оптимизации по достижении достаточной производительности.

Примерно так.

PS:
На моей практике бывали случаи, когда приходилось брать чужой усосаный хаками для производительности код, переименовывать всё и вся, убирать хаки и т.п., после этого разбираться с логикой и делать тесты. Рекордный случай - удаление порядка 17 тысяч в кадр(!) лишних вызовов методов.

Ни в одном из случаев процесс оптимизации не доходил до того, чтобы заменять циклы for на while или заменять типы данных или вызовы математических методов.
Процесс оптимизации прекращался задолго до этого, на уровне изменения логики приложения.

PPS:
И да, не юзайте чужие хакерские приемы не проверив. И в этом топике в коде есть ошибки.
Четко отдавайте себе отчет, готовы ли вы взамен на выигрыш в 0.0003 миллисекунды жертвовать читабельностью кода и риском внесения ошибки.

[Iv]

WindWalker, согласен. Но тогда, наверное, не стоит подменять понятия и говорить именно о тонкостях внутренней механики, а не об оптимизации.

[Gaen]

Сообщение от Iv

- я бы сказал читабельность и простота кода. Следование стандартам написания кода. Правильное и значимое именование. Отказ от хаков.
Знание и правильное применение хорошей практики, в частности, шаблонов проектирования.
Как итог - понятный и логичный код без ошибок и лишних операций.

Это прямо таки повод для холивара

Просто сейчас всё идёт в сторону разрастания итак громоздкого кода ради его универсальности. Т.е. в итоге жертвуем производительностью в пользу удобства написания (прочтения, понимания, отладки, редактирования) кода. Эта позиция понятна: железо постоянно совершенствуется, поэтому теперь можно себе такое позволить.

А почему бы не продолжать писать продуманный код, получая выигрыш в скорости при совершенствовании железа?

Фреймворки и паттерны это удобно. Это и хорошо, ведь всё-таки их далеко не дураки придумывали. Тем не менее они все являются стандартизованными для общего случая. А общее решение, как известно, проигрывает решению, найденному для данной конкретной ситуации.

Конечно для этого требуется более высокая квалификация кодера, но на то он и программер чтобы думать. Недостаточно просто выучить язык, нужно уметь правильно всё придумать и организовать.

Сейчас программить становится всё легче и легче, соответственно растёт число быдлокодеров, которые пишут тормозной код, потому что его легче всего написать.

Можно много ещё чего написать, вернуться к тому что я ни в коем случае не говорю что использовать паттерны это плохо итд, но я пожалуй пока остановлюсь. Ибо нахожусь немного в неадеквате

С удовольствием выслушаю всё, что мне на это ответят

[Iv]

GAIKER, я не вижу никакого противоречия.
Вот ты написал приложение, оно устраивает и тебя и заказчика по производительности.
Будешь ли ты его оптимизировать? И, даже если будешь, то до какой степени? Нужна ли везде максимальная производительность? Как определить, что производительность уже максимальна и достигнут предел?

Моя практика показывает, что вообще довольно редко доходим до этапа оптимизации кода.
Но в том-то и дело, что оптимизация - отдельный этап и часто обратный универсализации.

В этом ряду совершенно особняком стоят публичные библиотеки кода, поскольку заведомо неизвестно где и на какой нагрузке их код будет работать.
Но и здесь имеется предел, дальше которого не стоит оптимизировать код только потому, что выигрыш ничтожен по сравнению, например, с накладными расходами на вызов метода.