Важно ли, чтобы решение было эффективным?

Я решаю много проблем, в основном из Top Coder. Я получу ответы на многие вопросы, но в большинстве случаев я получаю неэффективное решение.

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

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

^^^ Это единственное, что вам действительно нужно взять из этого ответа. ^^^

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

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

Я бы согласился с Майком Челлини, я бы добавил одно.

Является ли что-то "достаточно эффективным"? Например, с точки зрения пользователя, нет большой разницы между функцией, которая завершается за 0,00001 секунды, или функцией, которая завершается за 0,1 секунды, даже если одна из них намного эффективнее другой. Функция, выполняемая за 10 минут, не сильно отличается (для пользователя) от функции, выполняемой за 12 минут. В обоих случаях пользователь получит чашку кофе или выполнит другое задание.

Я пришел к мнению, что эффективность - это «эффективный пользователь», а не эффективный алгоритм.

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

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

• Некоторые учащиеся использовали простой цикл и формулу, чтобы проверить правильность чисел и отобразить их, медленно, но выполнив задание, O (n ^ 3).
• Другие студенты провели исследование и нашли формулу, которая лучше проверяла правильность заданного числа, эти программы работали намного быстрее, O (n ^ 2).
• Один студент использовал медленную формулу для генерации значений, а затем скопировал их в константный массив в своем коде и отобразил его содержимое, O (n).

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

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

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

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

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

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

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

Наконец, курсы информатики становятся все более доступными в Интернете и будут охватывать фон, который вам необходимо улучшить.

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

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

Как сделать ваш код более эффективным:

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

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

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

Как правило, в реальном мире это не имеет значения. Одна из ключевых идей разработки программного обеспечения: «Не оптимизируйте то, что не знаете, нуждается в оптимизации», затем «Оптимизируйте только тогда, когда доказано, что это необходимо».

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