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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Применительно к сетевым технологиям краткость - это производительность. Если ваш веб-сервер предоставляет небольшой фрагмент javascript на каждой странице, не помешает сократить имена переменных. Поднимите www.google.com и посмотрите источник!

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

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

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

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

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

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

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

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

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

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

1. Написание меньшего количества строк кода, как правило, лучше по целому ряду причин. Например, чем меньше кода, тем меньше вероятность ошибок. См., например, эссе Пола Грэма "Краткость - это сила"
2. Несмотря на это, уровень, достигнутый в Code Golf, обычно выходит далеко за рамки разумного. В Code Golf люди пытаются написать код как можно короче, даже если они знают, что он менее читабелен.
3. Эффективность - это гораздо более сложная вещь. Я полагаю, что меньший объем кода обычно более эффективен, но есть много случаев, когда это не так .

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

По двум причинам:

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

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

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