Производительность Java: true vs. Boolean.TRUE
Что из следующего лучше с точки зрения производительности и эффективного использования памяти?
Boolean isItTrue(arg){
return Boolean.TRUE;
}
boolean isItTrue(arg){
return Boolean.TRUE
}
Boolean isItTrue(arg){
return true;
}
boolean isItTrue(arg){
return true;
}
Должно быть быстрее и проще работать с примитивными типами, но, с другой стороны, при использовании ссылки на статический объект, новое значение не создается. Или он оптимизирован на уровне компилятора, и все true и false заменены ссылками на статические объекты для экономии памяти?
4 ответа
Во-первых, преимущество в производительности при использовании любого из них , скорее всего, слишком мало, чтобы быть релевантным. Простота кода / удобочитаемость / удобство сопровождения гораздо важнее ... в подавляющем большинстве случаев.
Ни один из примеров не включает создание Boolean экземпляров. Теоретически возможно, что 3 из 4 вызовут инициализацию класса Boolean ... и что ваше приложение иначе не сделало бы этого. В этом крайне маловероятном событии все ваше приложение выделит 2 объекта, которые иначе не были бы выделены.
Этот будет равен или быстрее, чем все остальные, потому что это просто влечет за собой установку регистра в ноль.
boolean isItTrue(arg){
return true;
}
Взятый отдельно, он должен загружать статическую ссылку из памяти, а не обнулять регистр. Тем не менее, JIT-компилятор может быть в состоянии оптимизировать это в некоторых случаях.
Boolean isItTrue(arg){
return Boolean.TRUE;
}
На первый взгляд, это включает вызов Boolean.valueOf(true) для «упаковки» true, но JIT-компилятор должен иметь возможность оптимизировать его под тот же код, что и предыдущий вставив вызов.
Boolean isItTrue(arg){
return true;
}
На первый взгляд, это включает в себя призыв к Boolean.booleanValue(Boolean.TRUE) «распаковать» Boolean. Этот звонок может быть встроен. Также возможно, что JIT-компилятор может избежать загрузки ссылки на объект Boolean и извлечения его поля значения.
boolean isItTrue(arg){
return Boolean.TRUE
}
Суть в том, что относительная производительность 4 альтернатив зависит от того, насколько успешным будет JIT-компилятор в оптимизации. Это будет зависеть от контекста, специфики JIT-компилятора, настроек JVM и так далее. В лучшем случае JIT-компилятор может (по крайней мере, теоретически) создать один и тот же (оптимальный) код для всех из них.
Последний
boolean isItTrue(arg){
return true;
}
Я использую Boolean, только если метод иногда должен возвращать null
Пользуйся ясностью для сопровождающего кода по таким микрооптимизациям. Вопрос не должен быть «который меньше / быстрее», во-первых, который выражает то, что вы имеете в виду.
Если метод возвращает логический объект, то всякий, кто получает, должен решить, существует ли вероятность того, что он может быть нулевым, и что, если он равен , равен нулю, это может означать что-то отличное от true / false, как "мы не знаем".
Так что возвращайте тип логического типа, если вы это имеете в виду, в противном случае, если вы хотите разрешить Null, тогда Boolean.
Если возвращается логическое значение, то
return true; // or false
должно быть лучше, чем полагаться на автобокс, опять же для ясности и производительности.
Если возвращено логическое значение, то
return Boolean.TRUE
должно быть хорошо, оно просто избегает создания дополнительного мусора, хотя я против микрооптимизации и не вижу смысла в том, чтобы быть преднамеренно неэффективным. Я бы сказал, что яснее также то, что вы явно сопоставляете тип возвращаемого значения.
Используйте последний (просто boolean). Даже если компилятор оптимизирует их все до одного и того же, по крайней мере вы облегчаете работу компилятора (это не простая работа, вы знаете!).
Плюс это меньше нажатий клавиш (не нужно нажимать Shift). Но на самом деле единственная причина, по которой вы должны использовать класс-обертку, - это когда вам нужна возможность установить его на null и для использования в общих структурах данных, таких как LinkedList<E>.