Можно какой нибудь линк на эту тему?
> Существует общая рекомендация разгружать конструктор. Т.е., ставить там
> сохранение аргументов (если приходят) и вызов процедуры инициализации. И
> больше ничего туда не пихать. А вот почему?
- я даже не сохраняю там аргументы никогда.
В моем коде в конструкторе только вызов метода initInstance с
передачей ему всех аргументов конструктора. И за редким исключением
это всё.
Причина проста: код в конструкторе выполняется обязательно и в
подклассе его никак не переопределить. В то время, как initInstance
запросто переопределяется и делай что хочешь.
Никакие другие мотивы мне неизвестны.
О©╫! О©╫О©╫О©╫О©╫О©╫О©╫О©╫!
О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫!
> А переопределять конструктор наследуемого класса это разве хорошая
> организация кода?
- в идеальном случае - не очень хорошая практика.
Но, поскольку идеальных случаев не бывает, то вместо догматов я
предпочитаю гибкость. Чтобы впоследствии иметь возможность без проблем
решать свои задачи не залезая в нормально работающий и оттестированый
родительский класс.
Если что и сломаю, то только новое. Старое будет жить как жило.
> Code inside the constructor is not optimized by the Just-in-time compiler (JIT).
- круто, спасибо, не знал.
читай линку выше http://juick.com/blooddy/560275
Нет, оно вообще не вкомпиливается.
Денис Коляко
______________________________________________________________________
e...@timezero.ru | http://etcs.ru/ | http://timezero.com/
хак - штука небезопасная.
Хаки полезно знать как особенности реализации данной версии языка или
компилятора.
Но если завтра компилятор неожиданно станет умнее настолько, что
поймёт что !true равно false, то кое-кого у нас порой ждет какое-то
количество бессонных ночей в поисках неизвестно откуда взявшейся
кое-какой ошибки.
Пользуясь случаем передаю привет создателям фильма "Следствие ведут знатоки".
А вот моё мнение по поводу тяжести конструкторов....
Допустим, есть некий базовый класс для контролов с текстом:
public class MyBaseControl extends Sprite {
public var textField:TextField;
public function MyBaseControl() {
textField = new TextField();
addChild(textField);
}
}
Затем понадобилось сделать класс MySpecificControl, который наследует
от MyBaseControl, но в котором вместо TextField должен использоваться
MegaCoolTextField - наследник TextField с дополнительным функционалом.
Это получается, что теперь в конструкторе MySpecificControl надо
сперва убить старый textField, затем создать и добавить новый.
Таким образом небольшой перевес в конструкторе класса может привести к
куда более серьёзному утяжелению конструкторов потомков.
А не изврат ли?
Допустим, этот MegaCoolTextField не содержит новых публичных методов и
свойств, но зато умеет вводить кириллицу в любой ОС, закрашивает буквы
градиентом и сразу поддерживает i18n.
То есть с точки зрения API ничем не отличается от TextField, но при
этом разительно отличается поведением и внешним видом.
> Думаю причина рекомендации именно perfomance а
> не код интерпретируется или компилируется.
- производительность - самое последнее чем стоит озаботиться в
процессе написания программы. Ну и смешно говорить о разнице в
производительности в данном случае. Главная задача - написать
качественный код без логических ошибок. И только, если в итоге
окажется, что где-то есть затыки производительности, заняться
выяснением причин и их устранением.
На этот случай есть оператор as.
> Я всёшки надеюсь, что Реалакси не окажется аццким тормозом. :)
- хорошая производительность основывается на правильной архитектуре и
использовании правильных алгоритмов, а не на микрооптимизациях где
нужно и не нужно.
Факт замены одного выражения на другое с производительностью в два
раза выше, как это ни странно, не дает ничего. Поскольку абсолютный
выигрыш составляет одну тысячную миллисекунды в момент выполнения
данного кода. А код этот вызывается в среднем раз в минуту например.
Есть ли смысл?
В то же время в заоптимизированном бардаке легко неверно что-то понять
и допустить ошибку, которая будет стоить сотен миллисекунд и долбить
постоянно.
Приведу пример:
как-то году в 2002-м я взял чьё-то готовое древовидное меню и вполне
успешно его пользовал в проекте до тех пор, пока меню не стало большим
- больше 500 элементов. Тут оно стало жутко тормозить при
открытии/закрытии веток. Полез изучать код и обнаружил, что при
открытии папки код пробегался дальше по всем элементам дерева
пересчитывая их позицию и... вызывая аналогичный метод в каждом из
них.
В итоге - лавинообразное увеличение - порядка 100 тысяч(!!!) абсолютно
ненужных вызовов.
При этом, в коде автор явно пытался бороться с проблемами
производительности - большинство известных на том момент
микрооптимизаций в коде были были применены. Но не помогли.
При оптимизации производительности куда важнее выявить настоящую
проблему, чем молотить по всему коду микрооптиизациями.
ну вот заглянте сюда:
http://je2050.joa-ebert.com/files/misc/as3opt.pdf
выигрыш в самом крутом случае составляет 30 секунд на миллион итераций. Много?
При ста итерациях около трех миллисекунд, т.е. выигрыш от оптимизации
составит три сотых миллисекунды на операцию.
Т.е. в нормальном коде без циклов или при пробежке по небольшому
списку смысл оптимизации отсутствует напрочь.
И это заметьте - в самом крутом примере. Остальные примеры дают
считаные десятки миллисекунд выигрыша на миллион итераций. Т.е. вообще
ничего не стоят. Вообще. Ничего. Ноль.
Все эти техники микрооптимизаций есть смысл применять когда идет
перебор огромного количества элементов.
Но и тут есть смысл в первую очередь посмотреть на возможность
изменения алгоритма, предварительной подготовки данных и изменения их
структуры, кэширования и т.п. В идеале, оптимизация должна привести к
отказу от перебора большого массива данных.
И вот только после всей этой работы, если всё-таки вышеперечисленное
не удается, есть смысл применять техники микрооптимизаций. В чётко
обозначенном месте, твёрдо понимая необходимость, оставив при этом
закомментированный оригинал для сравнения и понимания алгоритма.
Теперь по поводу итераций.
Обработка картинки размером 800x600 - это 480 000 итераций. То есть
всего двое меньше миллиона.
Понятно дело, что есть фильтры и шейдеры, но они не всемогущи, иногда
приходится использовать AS.
> То есть 3 миллисекунды - не такая уж и ерунда.
- 3 миллисекунды это очень много. И выигрыш этих трех миллисекунд при
микрооптимизации происходит в основном на десятитысячных итерациях и
выше. Я не помню, когда в последний раз делал код с таким количеством
итераций. И если делал, то разумеется понимал, что это
высоконагруженный код и применял оптимизацию.
Но в обычном коде выигрыш от микрооптимизации ровно ноль.
> Обработка картинки размером 800x600 - это 480 000 итераций. То есть
> всего двое меньше миллиона.
- ты привел именно тот пример, когда микрооптимизация имеет хоть
какой-то смысл.
Но есть вторая сторона медали: лишь часть кода может быть
оптимизирована. Не весь. И далеко не факт, что основное количество
тормозов добавляет оптимизируемый код.
Микрооптимизациями скорее всего удастся добиться не более чем 1%-10%
ускорения работы кода, а то и меньше. Т.е. твоя картинка будет
обсчитываться не 30 секунд, а 27-29.
- Есль выигрыш?
- Есть.
- Стоит за него побороться?
- Возможно.
- Решит ли это проблему?
- НЕТ.
Для пользователя 10% разница в ожидании почти незаметна.
Да, в таком случае лучше попробовать оптимизировать, чем нет.
Но проблему это всё-таки не решает.
Так что даже в тех случаях, когда вроде есть смысл применить
микрооптимизацию, это необязательное действие и стоит 100 раз
подумать, прежде чем применять. А после применения сделать тесты
производительности и отказаться, если выигрыш составляет считанные
проценты - а именно так скорее всего и будет.
Прекрасно, прекрасно...
Правда, когда я говорю за оптимизацию во Флаше, то имею ввиду изничтожение ненужных хиттестов\онЕнтерФреймов и прочих "тяж0лых" техник, типа разных 3Д-движков, где они на фиг не нужны.
Тут вот игрушку принесли - на сцене ничего не происходит, а процессор в небо и практически все виснет! А все потому, что создатель тупо засунул ВСЮ логику игр в онЕнтерФрейм, который вызывается всегда!.. Высчитывает свои нули. Огромный, длинный, страшный с множественными вложениями и подвызовами онЕнтерФрейм-ов...
Это, собственно, ошибки алгоритмизирования.. А вы мне тут про микрооптимизaции рассказываете... Как не стыдно!
test();
На моей машинке пишет 6-7 миллисекунд.
А это всего один цикл, причём по массиву, в котором всего один элемент.
В больших проектах таких циклов может быть много.
Разряжённые массивы - не такая уж и редкая вещь.
Т.е. в принципе, вполне реальный пример. 6 миллисекунд.
Если заменить try...catch на if, то время выполнения падает до 0
миллисекунд. Солидный выигрыш.
Кстати, спасибо за доку.
Теперь я знаю, почему мой проект подлагивает :)