Производительность: если еще vs switch, а vs for, для каждого vs for, print vs printf
Я тестировал все эти различные конструкции, используя getrusage() рассчитать вариации (ru_utime + ru_stime) до и после их выполнения.
Оказывается, нет большой разницы в выполнении той же задачи для аналогичных конструкций. Вот результаты:printf (1,5 ± 0,5)% быстрее, чем printforeach (6,0 ± 1,0)% быстрее, чем for цикл (итерация по индексируемому массиву из 1kk элементов)for (9,0 ± 1,0)% быстрее, чем while петляif/else (8,0 ± 1,0)% быстрее, чем switch(проверено в двух случаях, 6 случаях и 10 возможных случаях).
Так что мне было интересно, действительно ли эти различия имеют значение? Если мы используем все наиболее эффективные такие конструкции в нашем коде, будет ли это иметь какое-то значение? Может быть, 6%, 8% там, 9% или 10% там, подведя итог, изменит эффективность нашего кода?
Или эти различия, тем не менее, будут незаметны, я имею в виду, что ответ сервера на запросы почти не будет меняться? Кроме того, если мы используем if/else над switch, for над while, printf над print, foreach над for, это съест больше ОЗУ?
Решение
Отвечая на ваш вопрос, используя StackOverflow ответы, с точки зрения производительности:
За if/else против switch: Та же производительность (Больше).
За for против foreach против while: Не имеет значения (Больше).
За printf против print: Одно не лучше другого (Больше).
Мое скромное мнение заключается в том, что вы используете то, что кажется вам более удобным и / или лучше удовлетворяет ваши потребности (между ними существуют небольшие различия, в отличие от производительности, и это зависит от того, что вам нужно). С точки зрения производительности, есть и другие вещи, которые вы должны позаботиться, чтобы максимизировать производительность, такие как уменьшение O сложность кода, используемого в вашей программе, обработка сетевых задержек, распараллеливание задач при необходимости и т. д. Ваш вопрос немного общий, поэтому я попытался ответить тем же.
Другие решения
- Вы правы. Немногие проценты на самом деле не имеют значения.
- Масштабируемость операций может значительно влиять на производительность вашего приложения, чем эти несколько процентов. В этом смысле масштабируемость означает, как ваша система будет вести себя, если вы получите в 2, 10 раз больше данных. Будет ли ваша система замедлена только в 2 раза, 10 раз (если она линейна) или в 4 раза, 100 раз (квадратично) и т. Д. http://en.wikipedia.org/wiki/Scalability
- Эта проблема обычно возникает на стороне базы данных, как и другие упомянутые. Есть «большие» операции. Есть данные, которые могут быть большими.
- Большинству разработчиков не нужно слишком заботиться о ресурсах. И да. профилирование — это правильный способ решения проблем с производительностью.
ОП пишет:
Эти различия действительно имеют значение? Если мы используем все наиболее эффективные такие конструкции в нашем коде, будет ли это иметь какое-то значение?
Ну да и нет. Вы программируете приложения со сверхнизкими задержками? Жесткие (детерминированные) приложения в реальном времени? Если да, то да. Ожидание ввода с клавиатуры от пользователя? Это чудо, что ваш процессор не умирает от скуки. Так что нет.
Разница в 9% может быть незначительной (ваш эльфийский лорд не убивает тролля), или она может быть чрезвычайно значительной (система жизнеобеспечения вашей бабушки убивает ее).
По сути, это не тот вопрос, на который можно ответить здесь. Оставляя в стороне вопросы оптимизации среды / исполнения / компилятора: это не только вопрос длины книги, но и конкретная книга будет зависеть от того, о каких программах вы говорите, и каковы последствия и требования к производительности. Я предполагаю, что для 99,99% программистов разница между switch или же if/else утверждение, или подобная оптимизация глазка, является (в реальном выражении) абсолютно нулевым.
Старый принцип «сделай его читабельным, запусти его, а затем сделай его быстрым, если нужно» — это, вероятно, твой лучший образ действий. Даже в этом крайне редком случае, когда это может иметь значение, просто используйте профилировщик, чтобы определить, где действительно необходима часть «где» фазы «заставьте его работать быстро».