Оптимизирует ли современная JVM простое встроенное анонимное распределение классов?

Question

Сегодня я получил замечание о проверке кода, чтобы извлечь этот анонимный класс в поле, чтобы избежать его повторного выделения:

Collections.transform(new Function<Foo, Bar>(){
  Bar apply(Foo foo) {
    // do some simple local transform of foo into a Bar.
  }
});

Я ответил, что «это не имеет значения, JVM оптимизируетЭто".Хотя я точно знаю, что эта «оптимизация» никак не повлияет на производительность, и я думаю, что дополнительная ценность наличия встроенного кода стоит того, но мне любопытно, был ли я прав в отношении оптимизации JVM.Итак, мой вопрос - это предлагаемый рефакторинг абсолютно бездействующий , потому что JVM все равно его оптимизирует, или здесь есть какой-то крошечный теоретический прирост производительности?

Answer 1

Я бы не особо ожидал , чтобы это оптимизировало, нет.

Нужно было бы убедиться, что Collections.transform никогда не спрятал Function, и что методсамо по себе никогда не делает this видимым и т. д. Очевидно, что все это выполнимо - но потенциально это будет довольно большая работа для относительно небольшого выигрыша в очень немногих ситуациях.

Теперь то, что делает любая конкретная ВМ, трудноскажем, без очень тщательного изучения - но я думаю, что «это не окажет существенного влияния на производительность» - это более разумная вещь, чем «JVM оптимизирует ее».

Answer 2

Независимо от того, извлекаете ли вы его в поле или нет, действительно должно зависеть от того, как часто вы его вызываете и как долго длится родительский класс.Если родительский класс живет так же долго, как приложение, и вы вызываете эту вещь один раз в голубой луне, зачем беспокоиться о том, чтобы удерживать экземпляр для такой тривиальной операции?И наоборот, если вы вызываете эту вещь часто, то да держите ее в переменной, чтобы избавить от необходимости создавать несколько объектов.

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

Answer 3

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

List<Bar> bars = new ArrayList<Bar>();
for(Foo foo: foos) {
   // do some simple local transform of foo into a Bar.
   bars.add(bar);
}

Лично я нахожу это проще.

Answer 4

Я не думаю, что JVM оптимизирует его - скорее всего, снижение производительности не стоит затрат на оптимизацию. Однако огромные преимущества встроенного кода значительно перевешивают его.