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

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

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

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

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

Да, это вариант, но такой кластер весьма дорогой обычно. Я обхожусь 2 компами дома. Уже больше 1.5 лет считаю сложную задачу в теории чисел. Но вот факт - у меня идёт перебор вариантов с некоторыми ограничениями, которые не сильно облегчают жизнь. Насколько-то помогают, но очень тормозной скрипт. А вот иностранный программист написал программу, которая считает в сотни раз быстрее. У него там особый алгоритм какой-то. Правда, для 64-битных компов.

Да, действительно, может, это и не оптимизация в чистом виде, а просто переделка алгоритма. Не очень хотел бы раскрывать детали, что это за программисты (их 2), но они действительно считаются неплохими спецами в этой области. Но не всемирно известные.

Вот вспомнилось пример оптимизации,вычитанный в какой-то заумной книжке
старайтесь не использовать в операторах их множественные условия, лучше разделите их на несколько операторов
пример
if (a>1) or (a<1) then
можно представить так
if (a>1) then
...
if (a<1) then
...

Цитата
motorway11 пишет: Здесь возникает одно "но" - ведь после первого if будет опять проверка производиться. Так что надо пользоваться else, а не просто писать if. Хотя у меня такой стиль составления if до недавнего времени преобладал

в приведенном примере else использовать можно,но если условий будет больше 2х else уже будет неверно. И добавить в IF безусловный переход, либо exit (если это приминимо, например для функции или процедуры)

Цитата
mihail filatov пишет: в приведенном примере else использовать можно,но если условий будет больше 2х else уже будет неверно. И добавить в IF безусловный переход, либо exit (если это приминимо, например для функции или процедуры)

Все-таки у меня появились сомнения - разве чем-то ограничено количество используемых else? Возможно, будет просто не так удобно читать код, но применять можно любое кол-во else. Или вы имели что-то другое в виду? Также можно просто использовать switch

У меня довольно часто встречаются проверки с такими условиями. Там есть либо OR, либо AND. В принципе, довольно интересно, можно ли их как-то оптимизировать. Обычно бывает где-то около 3-5 условий. При этом я почти всегда надолго задумываюсь, когда пишу OR или AND с отрицанием - надо еще понять, чем они отличаются То есть, по-русски обычно такие условия звучат так: "если это или не то, и то-то, то...". Когда проверок около 5, уже действительно можно запутаться Так что, во-первых, можно для всей конструкции присвоить специальное имя, а в if вставлять только его, а не лепить в скобках все - тогда их число становится большим. Во-вторых, оптимизировать иногда можно путем замены на обратные проверки или замены логических функций (это не всегда получается).

Вот, кстати, насчет оптимизации циклов - у меня довольно часто встречаются циклы, в том числе вложенные. Я часто использую for each. Можете ли вы привести советы по оптимизации циклов? Например, когда лучше использовать for each, когда наоборот, и что лучше по быстродействию.

Обычно у меня стоит выбор: либо брать цикл от 1 до N (которое можно обычно определить через свойство длины массива), либо For Each. Мне кажется, что для моих проблем они примерно одинаковы, хотя оптимизировать можно, теоретически. У меня обычно встречаются двойные циклы по таблице ячеек. Число итераций часто бывает в районе десятков тысяч, и тут должны, по идее, проявляться особенности выбора цикла. Кто из них тратит больше времени на доп. затраты и т.п. В последнее время стал чаще использовать цикл по i,j, а не For Each. Но обычно это опытным путем определяется. Тут вроде бы перекосов в ту или иную сторону нет, что лучше брать.
Правда, все время не поэкспериментируешь, так что какие-то общие рекомендации нужно все-таки знать.
А насчет ассемблера - хоть я его и изучал немного, на практике на нем ничего не писал. Чтобы на нем писать, нужно иметь большую ответственность - там уже все на низком уровне, так что надо полностью понимать, что делаешь .