Оптимизация
05.07.2010
комментариев 25
Параллельная ветка к ДЗ № 3.
Найдите общую мысль в следующих публикациях. Просто пробежаться глазами, в режиме сканирования.http://habrahabr.ru/blogs/htranslations/97857/
http://ru.wikibooks.org/wiki/Ruby/Идеология
http://www.xakep.ru/magazine/xa/123/102/1.asp
http://sergeybiryukov.ru/2008/02/prezhdevremennaya-optimizaciya/
Ну, и чтобы не забывали, с чем имеем дело:
http://www.forum.mista.ru/topic.php?id=456328&page=1
Это имеет отношение к оптимальному решению ДЗ № 3…
Вот что думаю по этой теме. Прежде чем программировать, нужно сначала крепко подумать.
Потом понять, а что мы собираемся оптимизировать:
– скорость работы
– объем памяти
– объем места, занимаемый на диске.
В зависимости от задач и оборудования свой критерий.
Как показывает практика, в большинстве случаев делают упор на скорость, память дешевле докупить.
Какие я к ней выдвигаю требования:
– переносимость кода (ассемблерные вставки, недокументированные возможности – все в топку)
– небольшая трудоемкость (10-15% от общего времени)
– значимый выигрыш (от 20%)
– понятность программы
– возможность развития
Порядок оптимизации вот какой:
1. убеждаемся, что все работает.
2. Ищем горячие точки. Нам ох как повезло, в конфигураторе есть профиллировщик свой.
2. Ищем правильный алгоритм или структуру данных. Катастрофический прирост обычно приходит от этого, а не от трюков с ключом компилятора.
Соответственно с опытом и постоянным самосовершенствованием мы будем все равно писать сразу более хороший код.
да, только надо понимать, что в основной своей массе мы пишем не код, а инструментарий для пользователей – это разные сущности. и оценки их эффективности – тоже разные. не имеет смысл плясать от радости как быстро и оптимально работает код, если он не удовлетворяет хотелок пользователя. Поэтому у меня на первом месте: 1. код должен работать как это требуется (пользователю);
.
конечно же, прежде чем делать то, что “хочет” пользователь – неплохо бы убедиться в адекватности этих хотелок – это отдельная большая тема/история ;-)
Для себя давно установил в порядке важности (то что выше – важнее):
1. код должен работать как это требуется (пользователю);
2. код должен быть легко читаем;
3. код должен испольняться быстро/быть оптимальным
.
в свое время, когда начинал 7-ку – конец 90-ых, никаких книжек не было, смотрел и читал код дтиповых конфигураций – все было ясно. как впрочем ясно было и до сих пор на типовых 7-ых ТИСах, БУХ. Что в текущих конфигах 8-ки – не знаю, но люди особой радости от читабельности и понятности кода (особенно запросов на 500 строк) – особого восторга не выказывают… Вышла УТ11 – говорят что код очень хорош…
Мое мнение код нужно писать оптимально сразу.
Пусть не максимально по быстродействию, тратя на это вагон времени, но приближаясь к идеалу.
В противном случае происходят не приятные вещи:Программист пишет код на базе где объем данных минимален (запуск нового проекта, копия базы без реальных данных и т. д.). Торопится, лишь бы работало.
Таких программистов не один.
Через пол года база выросла до приличного объема, начались жуткие тормоза.
И вот начинается оптимизация. :)
Сначала определить «узкое» место.
Потом разобраться в чужом коде.
Убедится в том что вагон реквизитов в запросе действительно нужен, не нужные убрать.
Переписать код на более оптимальный.
Убедится что это не затронуло другие блоки.
Опять вернуться к определению «узкого» места.
Сам через это прошел. Готов был оторвать руки тем кто писал «лишь бы работало». :)
: )))
Вот только это нужно сравнивать с заработанным за это время бизнесом доходом.
“Идеально через полгода” по деньгам может оказаться сильно хуже “good enough”….
Тут нужно учитывать не весь доход, а прирост от внедрения. :) Причем только на разницу времени старта промышленной эксплуатации. Как бы этот прирост умноженный в разы потом не ушел на оптимизацию. ;)
На самом деле мне не кажется что код оптимизированный под быстродействие занимает гораздо больше времени чем написанный как попало.
Скорость реализации функционала больше зависит от правильного выбора варианта реализации и квалификации программиста. Естественно должен быть баланс. Если оптимизация займет большой промежуток времени и приведет к незначительному приросту производительности, то она нецелесообразна. :)
Лучше – сразу писать красивый и по возможности оптимальный код. Когда это входит в привычку – с ужасом начинаешь смотреть на свой код годичной и более давности. Значит – развиваешься, растешь… :)
Долбить по клавишам со скоростью машинистки – возможно это и программирование, но не удовлетворяющий самого себя результат. А писать стоит так, чтобы самому было приятно от сотворенного тобой результата.
Ну и простите за бранное слово – ненавижу “говнокод” и “говнокодеров” (типа ТЗ1.Кол1 = ТЗ2.Кол2)!
Главная мысль – оптимизаторов – НАКУЙ (почти по Парабеллумовски….)
1. Делаем рабочий код – Код снимает проблемы? Решает задачи? – Да. Отлично. СТОП.
2. Если все устраивает – НЕ трогаем.
3. Впоследствии, если нужно, вернемся к нашему неоптимальному коду. Вылизывание, причесывание – потом…. После… Когда все (или почти все) заработает…
Я бы не был так резок : ) Все-таки, есть люди, которым просто сразу не нравится некрасивый код – имеют право сразу писать чисто и на скорость. Получается – отлично. Не получается – ну, значит да, пусть сначала заработает – а потом берем что есть как “контроль” и делаем вторую версию, сравниваем результаты и т.д.
P.S.
Марат, с Днем Рождения! : )
))) спасибо.
странная задача, выиграть 1% скорости, потерять читабельность(дальнейшее развитие) … ООП приводит к потере производительности, но приводит к читабельности и расширеню, чем просто обычное описание решения текущей задач …
ИМХО лучше потрять производительность и ускорить разработу программисту …
Читабельность – святое, не на ассемблере же пишем…
Но чтобы было понимание: Женя в своих решениях НЕ будет делать код легко читаемым, это тоже делается не случайно – это нужно для создания эффекта “преодоления”, чтобы срабатывало “О!!” при анализе решения, а не “просто глазами пробежаться”…
>>>чтобы срабатывало «О!!» при анализе решения, а не «просто глазами пробежаться»…
Вот это супер! Ведь стандартные приемы можно и в СП подсмотреть, и в типовых, и в литературе…
Коллеги, нам изюминок подавай! ))
Ну, Вы, утрируете. Излишняя оптимизация конечно вредна, но решать задачи перебором тоже не самый лучший вариант.
1. Оптимизация в “узком месте” – это оптимизация. Оптимизация не в “узком месте” – пустая потеря времени.
2. Попробуйте все-таки увидеть и другую точку зрения:
скорость разработки и наглядность (когда программист даже средненькой квалификации сможет понять код) для 90% кода важнее , чем выигрыш 470 миллисекунд. Тем более – в среде, которая сама убивает смысл скоростной оптимизации регулярного кода.
10% – это ежеминутно исполняемые процедуры или алгоритмы выборки/записи массивных данных…
Я с Вами полностью согласен. Но чем дальше тем больше точка зрения- сделаю сейчас абы как а потом когда нужно сделаю рефакторинг приводит к большому количеству не то что неоптимального, а плохого кода.
Оптимизация в виде сокращения переменных в циклах, количества присвоений и т.д. да это пустая потеря времени. А изменение алгоритма на такой же простой, но более эффективный – это помимо, хоть и возможно не нужного увеличения скорости еще и практика для мозгов. Хотя заниматься этим нужно действительно когда есть время.
Но как я и сказал я с Вами полностью согласен, и по крайней мере при данном обучении все эти споры не нужны и вредны. Люди не на то отвлекаются.
Сергей, мое суждение не абсолютно, Вы правы в том, что все время искать простой вариант – это не гуд для кармы, практику для мозгов тоже нужно устраивать.
В написании отчетов для 1С главное, чтобы пользователь не уснул, пока выполняется отчет :)
Ну вы товарищи даете. Сначала надаете задачек с юзюминками, потом покажете решения, тоже кстати не очень читабельные. Например по 2 заданию в возврате функции 3 знака равенства. Более читабельнее было бы использовать если. Или в 3 ем задании местами переменные менять без использования 3ей переменной тоже не очень читабельно. А потом говорите, эх куда же вас поперло.
: )))
Ровно поэтому выложен этот дополнительный пост – это балансировка, чтобы не кренило в одну только сторону…
Здесь у нас тренировочные задания, мы прокачиваем собственные навыки – но при решении прикладных задач у клиента действует больше факторов. Один из признаков хорошего коммерческого программирования – сначала сделать работающий прототип, и только потом его оптимизировать. Об этом и ссылки.
Спасибо за ссылки, очень было интересно.
Я стараюсь сразу писать наиболее оптимально, насколько хватает моих знаний. иногда предпочитаю написать больше понятного кода и такого который в дальнейшем проще менять, чем запихнуть всё в 10 строк, которые через месяц не поймешь, как исправить.
либо, когда гонят со сроками, пишу ” влоб”, чтобы читалось и работало без багов, насколько успеваю-отлавливаю.
сегодня вот понадобилось поискать по двум критериям из одной ТЗ строки в другой. Написал быстро велосипед, который успешно работает. зато он мой, и я знаю и уверен куда он поедет.
Это опять вопрос баланса : )
Если некоторый расчет производится неоднократно – будет некрасивым, если потом не вернуться и не проверить код на “затыки”…
Но не всегда на это есть время, и в большинстве случаев первоначальный код остается. А также срабатывает классическое “Работает – не трогай”. Пока в этот код не упрется разработчик, разбираясь: “а почему ж так медленно-то” :)
з.ы. за ссылочки спасибо
: ))