оптимизировать нада лишь после окончания программирования, после тестов с профайлером. раньше смысла нет. ну и плюс статистика - большая часть выполнения порграммы фокусируется в 10% строках кода. так что если будете оптимизировать весь код - потратите 90% времени впустую.
это актуально если тестится работа с большим объекмом данных, чтобы надежно поместить его в оп или кеш. а тут просто вызов, поэтому нам нужно удостоверицо что код в оп и в кеше проца. а для этого в принципе хватит его 1 раз вызвать. ну а 50 чтоб на случай если вдруг кто вытолкнет код из кеша.
ну пох =) просто имхо для данного случая результат будет принципиально разнИца при первом тесте, в остальных будет уже среднее значение. ну кароч кто как хочет, тот так и тестит
Ага, после "окончания программирования" оптимизировать как правило уже поздно, ибо код к тому моменту представляет собой мусорник без крышки.
Неправда Оптимизированный код читать куда сложнее чем неоптимизированный. Обычный процесс разработки: программирование как удобно, написание тестов и их прогон, рефакторинг, прогон тестов. И так до полного удовлетворения. Затем работа с профайлером, выяснение узких мест и их оптимизация. И вот после этого код уже вполне может стать не таким красивым и элегантным. (До этого код прост и понятен, в результате рефакторинга, главное рефакторить почаще) З.Ы. В общем, присоединюсь к Ra$cal, читайте Фаулера. З.З.Ы. Ну вообще тесты рекомендуют писать до написания кода, но у меня на практике так ни разу не получалось.
Кстати да. Забыл сказать, что я за первый вариант для веба. Больше пары десятков итераций на практике не встречается.
Лично для меня это не есть нормальный процесс разработки. Нормальный процесс разработки включает в себя имплементацию с соблюдением культуры кодирования, а не "как удобно". А она (культура) подразумевает и оптимизацию в том числе. Тестирование может выявить слабые места программы, которые затем нужно оптимизировать более тщательно. Но это не означает что остальной код должен быть грязным. Фаулер мужик неоднозначный, не нужно на него молиться как на икону, у него много спорных мест. К тому же, книга "Рефакторинг" не имеет никакого отношения к оптимизации, как тут уже замечали. PS И кстати на возможное снижение производительности при замене переменной на вызов метода - пишет сам же Фаулер в той же книжке.
Algol, дык рефакторинг для того и придуман, чтобы избавляться от грязного кода. А оптимизация (не считая алгоритмической), часто бывает избыточной, и отнимает слишком много времени, для этого и не следует оптимизировать пока не пробежишься по коду профайлером. Это делается после получения работоспособной версии. А задача тестов, не в том чтобы выявлять слабые места программы, а в том, чтобы гарантировать неизменность её работоспособности при последующих изменениях, в том числе при рефакторинге и оптимизации. (Ну или, если полностью следовать TDD, ещё показывает процент готовности приложения) Безусловно. Мало того, рефакторинг зачастую замедляет работу программы. Но при этом хорошо структурированный код проще будет оптимизировать.
он пишет о других типах методов. которые выполняют вычисления. гетеры и сетеры к этим типам методов не относятся.
Ну может ты и прав Хотя, это зависит от предметной области. Не думаю что в графических движках, например, оптимизация бывает "избыточной"
Пример из анекдота: "Мы переписали весь код на ассемблер, добившись повышения производительности на 3%, и увеличения времени дебага на 300%"
Algol, лучше написать 10 программ со 100% производительности, чем это же время потратить на 1 с 150%процентной. Ведь за деньги с 9 остальных программ можно купить железо на увеличение произвродительности на все 10000%.
все зависит от реализации того класса. он может хранить число элементов и менять переменную при модификации объекта(пушнули запись, проинкрементили коунтер), или же вычислять число элементов при каждом вызове. так вот тут как раз и кроется простор для оптимизации. вместо того, чтобы в каждом цикле делать int arrsize = arr.count() проще сделать внутри класса массива поле размера. собсно к этому и сводится рефакторинг =) все куски кода делаем очевидными, убираем дублирование кода, а потом в случае необходимости правим в некоторых местах, ибо одинаковый код по максималу убран. обрати внимание насколько проще это дело оптимизировать - всего в одном месте, и в самом логичном - в классе массива. но естественно есть варианты кода, где такое не канает, и понадобится другая оптимизация. ну или в случае, когда нет доступа к исходному коду. но тогда как вариант можно просто наследовать класс от этого или сделать фасад и добавить сию фишку руками.
Т.е. лучше завалить проект, но некоторую ее часть сделать чуть быстрее, чем сдать готовый проект? Дело в приоритетах. Я выбираю сдать проект.
Разве я это сказал? Разве оптимизация ведет к завалу проекта? К чему эти фантазии? Просто лично я (написать триста раз ИМХО?) привык писать код максимальный по быстродействию. Если я вижу что вариант с временной переменной быстрее (а для меня еще и читабельнее, интуитивно понятнее!) чем с многократным вызовом функции - то мне что, специально писать заведомо более медленный вариант? Только потому что так сказал Фаулер, и что это по фен-шую? Я автоматом выношу все вызовы функций из цикла, если они не зависят от параметра, и для меня это совершенно не составляет труда и времени, а потому ни о каком завале проекта речь не идет. Конечно, если оптимизация с сомнительной рациональностью занимает пол дня, я ее, разумеется, не делаю. Но если она у меня на автомате, зачем от нее отказываться?
я бы еще добавил - выбираю сдать проект, суметь потом этот проект поддерживать, исправлять и дополнять [added] если ты пишешь проект один - то никакой проблемы нету. но когда пишешь в команде - тут главным становится критерий читабельности, а не скорости. поэтому все и пишут читабельный код. потом профайлят, и узкие места приводят к менее читабельному виду. но таких мест не много и все счастливы - и клиент получил быструю программу, и разработчики могут с ней работать дальше. а вариант на ходу оптимазить все операции - нерационален. я раньше так же писал. долго писал =) потом понял что лажа это все. не стоит оно усилий потраченых. но это все дело вкуса. на фаулера никто не молится. просто находим с ним общие решения =)
Согласен, это работа программиста - писать адекватный код. Речь идёт о намеренной оптимизации с подобными заморочками, типа замены геттеров/сеттеров, публичным полем класса (в ущерб нормальной инкапсуляции), или к примеру намерянным разворачиванием цикла в N последовательных вызовов (в ущерб читабельности) и т.д. В общем, до прохода профайлером, оптимизации не должна идти во вред читабельности и возможности модификации программы + не должна требовать большого количества доп. усилий, т.к. ты до профайлера не можешь сказать, какие участки стоит оптимизировать в первую очередь, а на какие можно вообще забить.
