Повлияет ли итератор, окружающий оператор утверждения, на производительность производственной сборки?JAVA

Программисты JAVA общаются здесь
Ответить Пред. темаСлед. тема
Anonymous
 Повлияет ли итератор, окружающий оператор утверждения, на производительность производственной сборки?

Сообщение Anonymous »

Недавно я обнаружил оператор «assert» в Java и засорял им свое программное обеспечение во время его отладки. Моим первоначальным инстинктом было избегать создания операторов потока управления только для обработки операторов утверждения, но затем я понял, что эти операторы управления, вероятно, в любом случае будут удалены во время производственной сборки, поскольку их блок будет пуст. У меня сложилось впечатление, что они будут устранены JIT-компилятором.

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

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

Может ли кто-нибудь из вас скажите мне, будут ли следующие строки снижать производительность производственной сборки (с отключенным «assert», как по умолчанию)?

Код: Выделить всё

for (T obj : Collection){
assert obj.someProperty();
}
В качестве бонуса, что, если бы я был чем-то более сложным, включая недолговечные объекты, которые используются только для утверждений?

Код: Выделить всё

TreeMap map = new TreeMap();
int i = 0;
for (T obj : Collection){
map.put(i,obj);
assert obj.someProperty();
i++;
}
// assert something about map, then never use it again
Или метод, единственным эффектом которого является вызов «assert»?

Заранее спасибо!



Соответствующие выдержки из документации Oracle по оператору «assert»:

Здесь обсуждается, как удалить утверждения из файла класса, что меня не совсем беспокоит.


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

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

static Final boolean Asserts = ... ; // false для устранения утверждений

if (asserts) Assert ;


и из раздела часто задаваемых вопросов:


Почему бы не предоставить флаг компилятора для полного исключения утверждений
из объектных файлов? Это твердое требование, чтобы можно было
включить утверждения в поле для повышения удобства обслуживания. Можно было бы также разрешить разработчикам исключать утверждения
из объектных файлов во время компиляции. Утверждения могут содержать побочные
эффекты, хотя они не должны этого делать, и поэтому такой флаг может существенно изменить
поведение программы. Считается хорошим
то, что с каждой допустимой программой Java
связана только одна семантика. Кроме того, мы хотим побудить пользователей оставлять утверждения в объектных
файлах, чтобы их можно было включить в поле. Наконец, спецификация требует
, чтобы утверждения вели себя так, как будто они включены, когда класс запускается до его
инициализации. Было бы невозможно предложить такую ​​семантику, если бы
утверждения были удалены из файла класса. Однако обратите внимание, что
стандартная «идиома условной компиляции», описанная в спецификации языка Java
, может использоваться для достижения этого эффекта для
разработчиков, которые действительно этого хотят.


Подробнее здесь: https://stackoverflow.com/questions/209 ... -productio
Реклама
Ответить Пред. темаСлед. тема

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение
  • Нужна ли лямбда события? Повлияет ли это на производительность?
    Anonymous » » в форуме Android
    0 Ответы
    23 Просмотры
    Последнее сообщение Anonymous
  • Нужна ли лямбда события? Повлияет ли это на производительность?
    Anonymous » » в форуме Android
    0 Ответы
    21 Просмотры
    Последнее сообщение Anonymous
  • Как итератор может быть поднят в итератор ?
    Anonymous » » в форуме JAVA
    0 Ответы
    24 Просмотры
    Последнее сообщение Anonymous
  • Как итератор может быть поднят в итератор ?
    Anonymous » » в форуме JAVA
    0 Ответы
    26 Просмотры
    Последнее сообщение Anonymous
  • Macro C ++ для строковой литературы начинается итератор и конечный итератор
    Anonymous » » в форуме C++
    0 Ответы
    20 Просмотры
    Последнее сообщение Anonymous

Вернуться в «JAVA»