it-swarm.com.ru

Устаревшие советы по оптимизации Java

Существует ряд советов по повышению производительности, которые устарели с помощью компилятора Java, и особенно Оптимизация по профилю . Например, такая оптимизация, предоставляемая платформой, может радикально (согласно источникам) снизить стоимость вызовов виртуальных функций. VM также может включать в себя методы, циклическое развертывание и т.д.

Какие еще методы оптимизации производительности применяются, но на самом деле они устарели из-за механизмов оптимизации, существующих в более современных JVM?

42
Dan

Финальный модификатор методов и параметров методов совсем не влияет на производительность.

Кроме того, Java HotSpot wiki дает хороший обзор оптимизаций, используемых HotSpot, и того, как эффективно использовать их в коде Java.

23
Eugene Kuleshov

Люди, заменяющие String a = "this" + var1 + " is " + var2; несколькими вызовами StringBuilder или StringBuffer. На самом деле он уже использует StringBuilder за кулисами.

20
Paul Tomblin

Необходимо определить компромиссы времени и памяти перед началом оптимизации производительности. Вот как я делаю это для моего приложения, критичного к памяти/времени (повторяя некоторые ответы выше, чтобы завершить):

  1. Правило № 1 Никогда не делайте оптимизацию производительности на ранней стадии разработки. Никогда не делай этого, если тебе это действительно не нужно. Если решили это сделать, то:
  2. используйте профилировщик для поиска узких мест, просмотрите исходный код, чтобы найти причины узких мест;
  3. выбрать подходящую структуру данных с наилучшим соответствием заданным компромиссам времени и памяти;
  4. выбрать подходящие алгоритмы (например, итерация против рекурсии и т. д.);
  5. избегайте использования синхронизированных объектов из библиотеки Java, если вам это не нужно;
  6. избегать явного/неявного создания нового объекта;
  7. переопределить/повторно реализовать типы данных/алгоритмы, поставляемые с Java, тогда и только тогда, когда вы уверены, что они не соответствуют вашим требованиям.
  8. Используйте небольшие независимые тесты для проверки производительности выбранных алгоритмов/структур данных.
16
khachik

В 2001 году я сделал приложения для телефона J2ME. Это был размер кирпича. И почти почти вычислительная мощность кирпича.

Для того, чтобы Java-приложения работали на нем приемлемо, необходимо написать их как можно более процедурно. Кроме того, очень большое улучшение производительности заключалось в том, чтобы поймать переменную ArrayIndexOutOfBoundsException для выхода из циклов for для всех элементов вектора. Подумай об этом!

Даже в Android существуют «быстрые» циклы по всем элементам массива и «медленные» способы написания одного и того же, как упоминалось в видео Google IO о внутренностях dalvik VM.

Однако, отвечая на ваш вопрос, я бы сказал, что в наши дни крайне необычно микрооптимизировать подобные вещи, и я также ожидаю, что это будет на JIT VM (даже на новом Android 2.2 ВМ, которая добавляет JIT), эти оптимизации являются спорными .. В 2001 году телефон запустил интерпретатор KVM на частоте 33 МГц. Теперь он работает на Dalvik - намного быстрее VM, чем KVM - на частотах от 500 МГц до 1500 МГц, с гораздо более быстрой архитектурой ARM (лучший процессор даже с увеличением тактовой частоты) с L1 e.t.c. и JIT прибывает.

Мы пока не находимся в тех сферах, где мне было бы удобно выполнять прямое манипулирование пикселями в Java - либо на телефоне, либо на настольном компьютере с i7 - так что все еще существует нормальный повседневный код, для которого Java не достаточно быстра. Вот интересный блог который утверждает, что эксперт сказал, что Java - это 80% скорости C++ для какой-то тяжелой задачи процессора; Я скептически отношусь к тому, что пишу код манипуляции с изображениями и вижу порядок между Java и native для циклов над пикселями. Может быть, мне не хватает какой-то хитрости ...? : D

8
Will
  1. Не вызывайте сборщик мусора вручную, это снижает производительность в современных реализациях JVM.
  2. Integer вместо Long не сэкономит много места, но ограничит диапазон чисел.
  3. Избегайте созданных вручную классов Enum и используйте вместо этого встроенный Enum. Java 1.5 представила реальные Enums, используйте их.
4
Michael Shopsin

При использовании x64 JVM с RAM менее 32 ГБ:

64-битная JVM использует на 30-50% больше памяти по сравнению с 32-битной JVM из-за больших обычных указателей на объекты. Вы можете значительно уменьшить этот коэффициент, используя JDK6 +.

От JDK6u6p до JDK6u22 это необязательно и может быть включено путем добавления аргумента JVM:

-XX:+UseCompressedOops 

С JDK6u23 (также JDK7) он включен по умолчанию. Больше информации здесь .

2
Waldemar Wosiński
  1. «Преждевременная оптимизация - корень всего зла» (Дональд Кнут)
  2. Полезно оптимизировать только узкие места.
  3. Вы должны проанализировать код в каждой ситуации. Возможно, вы можете заменить TreeSet на быстрый HashSet, потому что вам не нужна функция сортировки, или вы можете использовать float вместо double (посмотрите на Android SDK).
  4. Если никакая техника не помогает, вы можете попробовать переписать кусок кода и вызвать его через JNI , чтобы нативный код работал.
1
Vladimir Ivanov

Я нашел ссылки выше устаревшими. Вот новый пример оптимизации Java: http://www.appperfect.com/support/Java-coding-rules/optimization.html

0
Zon