Ожидание также может быть полезно, чтобы помочь вам написать детерминированные модульные тесты. Это позволяет подождать, пока некоторое состояние в вашей системе будет обновлено. Например:
await().untilCall( to(myService).myMethod(), greaterThan(3) );
или
await().atMost(5,SECONDS).until(fieldIn(myObject).ofType(int.class), equalTo(1));
Он также поддерживает Scala и Groovy.
await until { something() > 4 } // Scala example
Удобочитаемость. Это позволит другим (или Вы позднее) определять то, что Вы пытаетесь выполнить. Если Вы позже найдете, что действительно необходимо волноваться о производительности, удобочитаемость поможет Вам достигнуть производительности.
я также думаю, что путем концентрации на удобочитаемости, Вы на самом деле закончите с более простым кодом, который, скорее всего, достигнет лучшей производительности, чем более сложный код.
Подавляющее большинство времени, я согласился бы с большей частью мира, что удобочитаемость очень более важна. Компьютеры быстрее, чем можно вообразить и только получение быстрее, компиляторы делают micro-optimzations для Вас, и можно оптимизировать узкие места позже, как только Вы узнаете, где они.
, С другой стороны, тем не менее, иногда, например, если Вы пишете небольшую программу, которая сделает некоторое серьезное перемалывание чисел или другую неинтерактивную, в вычислительном отношении интенсивную задачу, Вам, возможно, придется сделать некоторые высокоуровневые проектные решения с целями производительности в памяти. Если бы необходимо было попытаться оптимизировать медленные части позже в этих случаях, Вы в основном закончили бы тем, что переписали значительные части кода. Например, Вы могли попытаться инкапсулировать вещи хорошо в маленьких классах, и т.д., но если производительность является очень высоким приоритетом, Вам, возможно, придется согласиться на менее хорошо учтенный дизайн, который, например, не работает как много выделений памяти.
"Производительность всегда рассчитывает", не верно. Если Вы - связанный ввод-вывод, то скорость умножения не имеет значения.
Кто-то сказал "Причину, у нас есть раздутое программное обеспечение сегодня, то, что большинство программистов не хочет делать работу оптимизации", и это, конечно, верно. У нас есть компиляторы для заботы о тех вещах.
Любой компилятор в эти дни собирается преобразовать x*2
в x<<1
, если это подходит для той архитектуры. Вот случай, где компилятор БОЛЕЕ УМЕН, ЧЕМ ПРОГРАММИСТ.