Написание более короткого кода/алгоритмов является более эффективным (производительность)?

Ответ 1

Надеюсь, это не станет пламенной войной. Хороший код имеет много атрибутов, в том числе:

• Правильное использование прецедента.
• читабельность.
• ремонтопригодность.
• Производительность.
• Тестируемость.
• Низкая сигнатура памяти.
• Хороший пользовательский интерфейс.
• Повторное использование.

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

Ответ 2

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

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

Ответ 3

Написание решений "code golf" часто связано с тем, как "умный" вы выполняете работу самым кратким образом даже за счет удобочитаемости. Довольно часто, однако, более подробный код, включая, например, memoization результатов функции, может быть быстрее. Размер кода может иметь значение для производительности, меньшие блоки кода могут поместиться в кеш процессора L1, но это экстремальный случай оптимизации, и более быстрый алгоритм всегда будет лучше. Код "Code Golf" не похож на производственный код - всегда пишите для ясности и удобочитаемости решения, а не для терпения, если кто-нибудь, включая вас, когда-либо намерен снова прочитать этот код.

Ответ 4

Пробелы не влияют на производительность. Так что такой код просто глупый (или, может быть, оценка по гольфу была основана на подсчете персонажа?). Количество строк также не влияет, хотя количество выражений может иметь эффект. (исключение: python, где пробелы значительны)

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

Тем не менее, не зная ничего другого, делайте ставку на то, что больше утверждений является более крупным объектным файлом и более медленной программой. Но больше строк не делает ничего, кроме кода, более читаемого до точки (после чего добавление большего количества строк делает его менее читаемым;)

Ответ 5

Я не верю, что Code Golf имеет какое-либо практическое значение. На практике читаемый код - это то, что считается. Что само по себе является противоречивым требованием: читаемый код должен быть кратким, но все же простым для понимания.

Однако я хотел бы ответить на ваш вопрос по-другому. Обычно существуют быстрые и простые алгоритмы. Однако, если скорость является главным приоритетом, все может стать довольно сложным (и полученный код будет длиннее). Я не считаю, что простота равна скорости.

Ответ 6

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

Применительно к сети, производительность БРИСТИРОВАНИЯ IS. Если ваш веб-сервер обслуживает небольшой фрагмент javascript на каждой странице, это не помешает сохранить короткие имена переменных. Поднимите www.google.com и просмотрите источник!

Несколько раз DRY не помогает производительности. Например, Microsoft обнаружила, что они не хотят перебирать массив, если он не превышает 3 элемента. String.Format имеет подписи для одного, двух и трех аргументов, а затем для массива.

Существует много способов торговли одним аспектом для другого. Обычно это называется кэшированием.

Вы можете, например, отслеживать объем памяти памяти для скорости выполнения. Например, выполняя поиск вместо выполнения. Это просто вопрос замены() на [] на большинстве популярных языков. Если вы планируете это так, чтобы космический корабль в вашей игре мог двигаться только по фиксированному числу направлений, вы можете сэкономить на вызовах тригонометрической функции.

Или вы можете использовать прокси-сервер с кешем для поиска вещей по сети. DNS-серверы делают это все время.

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

Ответ 7

Абсолютно нет. Размер и производительность кода (хотя вы его измеряете) очень слабо связаны. Чтобы ухудшить материю, то, что аккуратный трюк на одном чипе/компилятор/ОС может быть хуже, вы можете сделать в другом архитекторе.

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

Ответ 8

• Написание меньших строк кода, как правило, лучше для нескольких причин. Например, чем меньше у вас кода, тем меньше вероятность ошибок. См. Например, эссе Пола Грэма, " Succinctness is Power"
• Несмотря на это, уровень, достигнутый Code Golf, обычно намного превышает то, что имеет смысл. В Code Golf люди пытаются написать код, который как можно короче, даже если они знают, что он менее читабельный.
• Эффективность - гораздо сложнее решить. Я предполагаю, что меньше кода обычно более эффективно, но есть много случаев, когда это неверно.

Итак, чтобы ответить на реальный вопрос, почему у нас даже есть соревнования по Code Golf, которые нацелены на низкий знак персонажа, если это не очень важно?

Две причины:

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

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

Короче говоря, я не думаю, что есть какие-либо способы проведения соревнований Code Golf style без использования "короткого кода" в качестве критерия.

Ответ 9

Это от "10 заповедей для разработчиков Java"

Keep in Mind - "Меньше больше" не всегда лучше. - Эффективность кода - это замечательно, но > во многих ситуациях писать меньше строк кода не повышает эффективность этого кода.

Это (возможно) верно для всех языков программирования (хотя в сборке оно может быть другим).

Ответ 10

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

Вот пример, где достаточно хорошо написанная программа была ускорена в 43 раза, а размер кода был уменьшен на 4 раза.

"Code golf" - это просто сжимающий код, например, перебивая студентов в телефонную будку. Я говорю об уменьшении кода, переписывая его в декларативной форме, например, на языке домена (DSL). Поскольку он является декларативным, он более непосредственно сопоставляется с его требованиями, поэтому он не надувается кодом, который существует только для реализации. Эта ссылка показывает пример этого. Эта ссылка показывает способ уменьшения размера кода пользовательского интерфейса аналогичным образом.

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

Ответ 11

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

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

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