LINUX.ORG.RU

Оптимизация кода


0

2

Как вы определяете до какой степени нужно оптимизировать код? Что выбрать Питон, или Си? Стоит ли стараться максимально сжать изображения для интернета? Где можно забить на валидность и читаемость гипертекста (тут особенно важно, ибо это вам не Си, гипертекст ведь постоянно по интернету гоняется)? Можно ли делать интернет-страницы из джейсона, или это — варварство? Стоит ли бороться за каждую итерацию, действие, команду?

С точки зрения экологии программного обеспечения - стоит. Ибо каждый лишний цикл, каждый лишний байт - приводит к бесполезной трате вычислительных ресурсов, пропускных мощностей, приводя только к излишнему потребление энергии и нагреву атмосферы (что в зимнее время воспринимается как благо).

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

azure ★★
()

Я использую старое правило - «не оптимизировать. а если оптимизировать, то только тогда, когда это жутко необходимо». У меня обычно оптимизация упирается в использование математики, и ограничивается несколькими функциями.

stolz
()

Может в зависти от задачи стоит решать эти вопросов? Морду для какого-нибудь wget можно писать на python, но кто будет писать на нём драйвер для железа или высоко сервер с 50к подключений в минуту? Стоит бороться за каждую итерацию в прикладе? Голова вам зачем дана? Чтобы есть, шапку носить и чтоб болела?

Dikar ★★
()

Надо руководствоваться практичностью: не ломать то, что работает и так, без оптимизации, без конкретной необходимости. Если необходимость появляется - оптимизируй, но опять же практично: если это даёт весомый эффект. А так-то, если код постоянно дописывается, сильно не наоптимизируешься «по-живому» :-)

Virtuos86 ★★★★★
()

> Как вы определяете до какой степени нужно оптимизировать код?
Пока затраты на оптимизацию не превысят пользу от неё.

>Стоит ли бороться за каждую итерацию, действие, команду?
В общем случае в качестве хобби разве что.

>Стоит ли стараться максимально сжать изображения для интернета?
На мегабитных каналах? Нет.


>Где можно забить на валидность и читаемость гипертекста (тут особенно важно, ибо это вам не Си, гипертекст ведь постоянно по интернету гоняется)?
Нигде.

>Можно ли делать интернет-страницы из джейсона, или это — варварство?
Можно делать из чего угодно. Даже из ручного труда китайцев, если на выхлопе будет читабельный, валидный хтмл.

schizoid ★★★
()
Ответ на: комментарий от schizoid

Можно ли делать интернет-страницы из джейсона, или это — варварство?

Можно делать из чего угодно. Даже из ручного труда китайцев, если на выхлопе будет читабельный, валидный хтмл.

То есть семантика не нужна? И то, что интернет превращается в кашу из флеша, джейсона и вообще что-то запутанное и непонятное — не плохо? Интернет всё менее и менее тёплый и ламповый.

sphericalhorse ★★★★★
() автор топика

Оптимизировать должен компилятор. Конечно это не отменяет выбора наиболее подходящих для задачи структур данных и алгоритмов. Ручной оптимизацией стоит заниматься только в случае выявления бутылочного горлышка профайлером и только в том случае, если без этого действительно нельзя обойтись.

m0rph ★★★★★
()
Ответ на: комментарий от sphericalhorse

То есть семантика не нужна? И то, что интернет превращается в кашу из флеша, джейсона и вообще что-то запутанное и непонятное — не плохо? Интернет всё менее и менее тёплый и ламповый.

Наверное, я тебя не понял правильно. Раскрой мысль подробнее.

schizoid ★★★
()
Ответ на: комментарий от schizoid

Наверное, я тебя не понял правильно. Раскрой мысль подробнее.

Чего непонятного? Интернет — это уже давно не старый добрый гипертекст, а

кашу из флеша, джейсона, и других приятных вещей.

sphericalhorse ★★★★★
() автор топика
Ответ на: комментарий от sphericalhorse

Т.е. генерировать страницы целиком на стороне пользователя? Нет, не нужно.

А json - просто способ хранения данных. Как РБД, plaintext, xml etc. Создать из данных страницу и отправить клиенту - что здесь плохого?

schizoid ★★★
()

Основной критерий - трудозатраты/выхлоп. Производиться должна на основании, например, каких-нибудь убедительных замеров и явных узких мест. Если оптимизация, (кулхацкерские трюки «я умнее компилятора» как ее некоторые понимают), не дает заметного профита в производительности/экономии ресурсов/затрудняет сопровождение кода - никому напрочь не нужна такая оптимизация.

slackwarrior ★★★★★
()

У меня так:
Сначала придумываю как реализовать задачу. При этом, стараюсь решить ее оптимальным способом (но для начала не сильно этим заморачиваюсь). Реализую, смотрю как работает. Если косяки - исправляю.
Далее, если никаких срочных и важных задач нет, то изучаю код снова, ищу слабые места, исправляю. Иногда смотрю что профилировщик выдаст.
Плюс, если читаю книги/статьи, вижу там годные советы - применяю их у себя (пример [java]: был у меня класс, в котором была ленивая инициализация. Потом встретил статью, в которой подробно разбиралась ленивая инициализация в java. Прочитал, нашел у себя косяки, поправил. Потом почитал Effective Java Блоха, запилил правильную статическую фабрику...и тд).
Ну и стараюсь не забывать, что с Микро-оптимизацией нужно быть осторожным и всегда оценивать, нужна ли она.

kovrik ★★★★★
()
Ответ на: комментарий от schizoid

Создать из данных страницу и отправить клиенту - что здесь плохого?

Отправить клиенту данные и создать страницу.


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

sphericalhorse ★★★★★
() автор топика
Ответ на: комментарий от slackwarrior

Если оптимизация, (кулхацкерские трюки «я умнее компилятора» как ее некоторые понимают), не дает заметного профита в производительности/экономии ресурсов/затрудняет сопровождение кода - никому напрочь не нужна такая оптимизация.

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

sphericalhorse ★★★★★
() автор топика
Ответ на: комментарий от sphericalhorse

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

slackwarrior ★★★★★
()

Как вы определяете до какой степени нужно оптимизировать код?

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

Что выбрать Питон, или Си?

Зависит от задачи и твоих скиллов.

Стоит ли стараться максимально сжать изображения для интернета?

Зависит от ситуации.

Где можно забить на валидность и читаемость гипертекста

На валидность - только если без нарушения валидности нельзя достичь цели (хз бывают ли такие ситуации). На читаемость - если гипертекст генерируется автоматически либо есть гарантия, что тебе никогда не придется его править.

Можно ли делать интернет-страницы из джейсона, или это — варварство?

Что такое джейсон?

Стоит ли бороться за каждую итерацию, действие, команду?

Зависит от ситуации. В общем случае - не стоит.

Deleted
()
Ответ на: комментарий от sphericalhorse

То есть семантика не нужна?

Нужна.

И то, что интернет превращается в кашу из флеша, джейсона и вообще что-то запутанное и непонятное — не плохо?

Плохо. Насчет флэша точно так же - нужен только если для его внедрения есть веские причины.

Deleted
()
Ответ на: комментарий от sphericalhorse

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

Как высоконагруженность с этим связана?

Deleted
()

Как вы определяете до какой степени нужно

Если явно «тормозит» - оптимизировать.

Стоит ли бороться за каждую итерацию, действие, команду?

Обычно нет - «экономия на спичках».

invy ★★★★★
()
Ответ на: комментарий от sphericalhorse

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

Не стоит опускать кавычки, скобки, отступы - код превратится в г*вн*. А если XHTML и нет кавычек - еще и не будет валидным.

Deleted
()
Ответ на: комментарий от sphericalhorse

Все зависит от того, каким образом он применяется. В общем случае он никак не нарушает суть и поэтому вполне может применяться.

Deleted
()
Ответ на: комментарий от Deleted

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

Как высоконагруженность с этим связана?

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

sphericalhorse ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Все зависит от того, каким образом он применяется. В общем случае он никак не нарушает суть и поэтому вполне может применяться.

А когда всё содержимое страницы передается в нём?

Если говорить конкретно про интернет, то он просто перестает быть «чистим», тёплым и ламповым.

sphericalhorse ★★★★★
() автор топика
Ответ на: комментарий от sphericalhorse

Ну так ССЗБ. И зачем самому мучиться с блогами и хостингами, если есть достаточно нормальных блогосервисов?

Deleted
()
Ответ на: комментарий от Deleted

Дык... Чтоб высоконагрузить - каша из флеша... и вообще что-то запутаннгое и непонятное в самый раз )))

slackwarrior ★★★★★
()
Ответ на: комментарий от sphericalhorse

А когда всё содержимое страницы передается в нём?

Такое редко встречается. Скинь ссылку хотя бы на один такой сайт - тогда будет о чем говорить. Вообще, если сайт совсем не работает без Javascript и этот сайт - не веб-приложение, которому без Javascript никак, то этот сайт г*вн* (кроме случаев, где в самом деле по-другому никак нельзя, а это встречается редко).

Если говорить конкретно про интернет, то он просто перестает быть «чистим», тёплым и ламповым.

ИМХО наоборот, начал становится «чистым», теплым и ламповым с момента выхода HTML4 и XHTML1, и это значительно ускорилось с изобретением чуть более «семантического» HTML 5. Жаль только, XHTML 2 забросили - ИМХО, была перспективная штука.

Deleted
()
Ответ на: комментарий от Deleted

А когда всё содержимое страницы передается в нём?

Такое редко встречается. Скинь ссылку хотя бы на один такой сайт - тогда будет о чем говорить.

Ссылки могу дать (tactoom и plurk хотя бы), но там не о чём говорить. Там почти всё оправданно.

sphericalhorse ★★★★★
() автор топика
Ответ на: комментарий от sphericalhorse

Ссылки могу дать (tactoom и plurk хотя бы), но там не о чём говорить. Там почти всё оправданно.

Вот именно. Когда оправдано - ничего плохого в этом нет.

Deleted
()

обычный trade off между скоростью написания и скорости работы.

Занимаясь чрезмерной оптимизацией рискуешь не закончить проект никогда.

Поэтому заранее шибко не оптимизируй, но закладывай в архитектуру возможности убыстрения если это потом понадобится.

true_admin ★★★★★
()
Ответ на: комментарий от sphericalhorse

для нормальной роботы блога менять хостинг около 20-ти раз.

так это любой блог на битриксе

true_admin ★★★★★
()
Ответ на: комментарий от Deleted

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

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

geekless ★★
()
Ответ на: комментарий от geekless

Граница необходимого решается просто:

Если приложение справляется со своей задачей, укладываясь в требования (по ресурсам, по времени, по задержкам, в конце концов разработчики сами результатом довольны), то дальше оптимизировать не стоит, пока не нарушится это условие. Иначе оптимизировать стоит.

Deleted
()
Ответ на: комментарий от Deleted

Этот критерий применим только для софта, разрабатываемого в конкретную коробку. В прочих случаях позицию разработчика часто можно охарактеризовать как «Проц не тянет? Выкини свой хлам. Мало рамы? Воткни больше.»

geekless ★★
()
Ответ на: комментарий от geekless

«Проц не тянет? Выкини свой хлам. Мало рамы? Воткни больше.»

Это бывает только если программа - наколеночная поделка студента с мощным компьютером :) Либо если это бетоальфа, где достаточно, чтобы «как-нибудь работало» :)

Deleted
()
Ответ на: комментарий от sphericalhorse

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

Плохому танцору яйца мешают.

tensai_cirno ★★★★★
()

Необходимой (и в большинстве случаев достаточной) оптимизацией является не использование недоязыков, by design дающих оверхеды по CPU и памяти в несколько раз, типа жавы и питона - последние можно использовать только для прототипирования и одноразовых поделок для себя, которые вообще не будут распространяться. А конкретные оптимизации ботлнеков - если есть специфические требования к времени выполнения - то пока они не будут удовлетворены, в противном случае на свой личный вкус. Максимально сжать изображения - почему бы нет, тем более что достаточно тупо загнать optipng в cron и забыть про него. Читаемость гипертекста не нужна вообще, валидность всегда нужна.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Необходимой (и в большинстве случаев достаточной) оптимизацией является не использование недоязыков

Почитай вступление и первую главу книги «Алгоритмы: построение и анализ». Кратко для Ъ: язык - фигня, решает оптимизация алгоритмов.

типа жавы и питона

Это не недоязыки. Как минимум, у джавы по процессору оверхед очень маленький, а не в несколько раз.

А конкретные оптимизации ботлнеков - если есть специфические требования к времени выполнения - то пока они не будут удовлетворены, в противном случае на свой личный вкус.

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

Deleted
()
Ответ на: комментарий от Deleted

Почитай вступление и первую главу книги «Алгоритмы: построение и анализ». Кратко для Ъ: язык - фигня, решает оптимизация алгоритмов.

Ну смотри. Язык таков, что при компиляции в начало программы добавляется malloc на полгига с заполнением мусором, а после каждой инструкции добавляется sleep. Теперь оптимизируй мне программу на этом языке чтобы она не жрала память и не тормозила.

Это не недоязыки. Как минимум, у джавы по процессору оверхед очень маленький, а не в несколько раз.

По процессору в разы, по памяти в десятки.

Тот же http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=java&am...

Но это синтетика, а из личного опыта - всё намного хуже.

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

Удачи :)

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Язык таков, что при компиляции в начало программы добавляется malloc на полгига с заполнением мусором

malloc не заполняет память ничем. А потому достаточно быстр.

а после каждой инструкции добавляется sleep.

Это только в твоей фантазии.

По процессору в разы, по памяти в десятки.

4.2. По процессору в пределах погрешности (в большинстве тестов и реальных применений), по памяти - зависит от конкретных случаев, но да - больше

Deleted
()
Ответ на: комментарий от Deleted

malloc не заполняет память ничем. А потому достаточно быстр.

Поэтому там и написано «с заполнением мусором», умник. Это именно то, что делает java.

а после каждой инструкции добавляется sleep.

Это только в твоей фантазии.

Да нет, это делает питон, потому что GIL. java - всего лишь тонны cache miss'ов по этим гигабайтам нагенерённого кода и никакая оптимизация, потому что, в отличие от нормальной компиляции, тут на неё банально не дают времени. Это твои «в пределах погрешности», на практике выливающиеся в те самые разы на задачах сколь-либо отличных от ничегонеделанья. Кроме того, на той же практике, т.к. использование жавы, по сути - выкидывание памяти в помойку, менее эффективно кэшируются данные на дисках, а насколько лишнее чтение с блина медленнее доступа к памяти можешь сам посчитать. Это не говоря уже о дальнейшем развитии событий, а именно полсистемы в свопе. Всё еле ворочается, жава не тормозит зато.

По процессору в пределах погрешности (в большинстве тестов и реальных применений), по памяти - зависит от конкретных случаев

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

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Поэтому там и написано «с заполнением мусором», умник. Это именно то, что делает java.

Java никаким мусором ничего не заполняет.

Да нет, это делает питон, потому что GIL.

GIL отражается только на многопоточных приложениях (у питона это слабое место).

java - всего лишь тонны cache miss'ов по этим гигабайтам нагенерённого кода

Какие такие гигабайты?

потому что, в отличие от нормальной компиляции, тут на неё банально не дают времени.

Тратится ровно столько времени, сколько нужно. И поэтому некоторые жабоприложения долго запускаются, даже если ничего не делают. Поэтому твой довод - фейл.

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

УЖС. Можно подумать, что жабе нужны гигабайты памяти. Естественно, это 4.2. А теперь пройди на acm.timus.ru, codeforces.ru, topcoder.com, SPOJ и прочие сайты подобной тематики и офигей от того, как люди на жабе без извращений вполне влезают в традиционные для таких соревнований ограничения по времени и по памяти (на тимусе, например, на большинство задач памяти дается всего 16 Мб). И подумай над тем, кто больше виноват в прожорливости приложения - жаба или кодер :)

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

Я не фанатик жабы и в данный момент на ней не пишу. Fail.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.