Имея столько системных ресурсов, насколько вы уверены, что ваш код настроен?

Question

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

Я помню время, когда вы могли оптимизировать кусок кода и, несомненно, ощутить улучшение производительности. Те дни почти прошли. Вместо этого, я предполагаю, что теперь у нас есть набор правил, которым мы следуем, таких как «Не объявлять переменные внутри циклов» и т. Д. Замечательно придерживаться их, чтобы по умолчанию вы писали хороший код. Но откуда вы знаете, что это не может быть улучшено без какого-либо инструмента?

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

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

Мне просто интересно узнать, какие инструменты вы используете для профилирования и измерения производительности кода, если вообще.

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

Почти весь код, который я пишу, достаточно быстр. В редких случаях, когда это не так, для C, C ++ и Objective Caml я использую почтенного gprof и превосходного valgrind с его превосходным визуализатором kcachegrind (часть KDE SDK; не обманывайте себя устаревшим кодом на sourceforge).

Стандартный компилятор ML MLton и компилятор Glasgow Haskell поставляются с отличными профилировщиками.

Хотелось бы, чтобы был лучший профилировщик для Lua .

Answer 4

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

С точки зрения бесплатных инструментов, проверьте gprof или oprofile , если вы находитесь в среде Unix. Они не так хороши, как некоторые из коммерческих инструментов, но часто могут указывать вам правильное направление.

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

Answer 5

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

Answer 6

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

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