Оптимизация по профилю имеет несколько предостережений, одно из которых упоминается даже в статье Вики, на которую вы ссылаетесь. Результаты действительны
- для заданных примеров, представляющих, как ваш код фактически используется пользователем или другим кодом.
- для данной платформы (ЦП, память + другое оборудование, ОС, что угодно).
С точки зрения производительности, существуют довольно большие различия даже между платформами, которые обычно считаются (более или менее) одинаковыми (например, сравнивают одноядерное старое Athlon с 512M с 6-ядерным процессором Intel с 8G, работающим на Linux, но с очень разные версии ядра).
- для данной JVM и его конфигурации.
Если какое-либо из этих изменений изменится, ваши результаты профилирования (и основанные на них оптимизации) больше не обязательно действительны. Скорее всего, некоторые из оптимизаций все еще будут иметь положительный эффект, но некоторые из них могут оказаться неоптимальными (или даже ухудшающими производительность).
Как уже упоминалось, JVM JIT делают что-то очень похожее на профилирование, но делают это на лету. Он также называется «горячей точкой», поскольку он постоянно отслеживает исполняемый код, ищет горячие точки, которые выполняются часто, и пытается оптимизировать только эти части. На этом этапе он сможет использовать больше знаний о коде (зная его контекст, то, как он используется другими классами и т. Д.), Поэтому, как уже упоминалось вами и другими ответами, он может выполнять более эффективные оптимизации как статический Он продолжит мониторинг и, если понадобится, позже выполнит еще один шаг оптимизации, на этот раз попытается еще сложнее (в поисках более дорогой оптимизации).
Работая с реальными данными (статистика использования + платформа + конфигурация), можно избежать оговорок, упомянутых ранее.
Цена - это дополнительное время, которое нужно потратить на «профилирование» + JIT-инг. Большую часть времени он провел довольно хорошо.
Я полагаю, что оптимизатор, управляемый профилем, все еще может конкурировать с ним (или даже превзойти его), но только в некоторых особых случаях, если вы можете избежать предостережений:
- вы совершенно уверены, что ваши образцы хорошо представляют реальный сценарий, и они не будут сильно меняться во время выполнения.
- вы достаточно точно знаете свою целевую платформу и можете выполнить ее профилирование.
- и, конечно, вы знаете / управляете JVM и его конфигурацией.
Это случается редко, и я думаю, что в целом JIT даст вам лучшие результаты, но у меня нет никаких доказательств этого.
Еще одна возможность получить выгоду от оптимизации на основе профилей, если вы нацелены на JVM, которая не может выполнить оптимизацию JIT (я думаю, что большинство небольших устройств имеют такую JVM).
Кстати, одного недостатка, упомянутого в других ответах, было бы довольно легко избежать: если статическая / профильная оптимизация медленная (что, вероятно, имеет место), то делайте это только для релизов (или RC, идущих к тестерам) или во время ночных сборок ( где время не имеет большого значения).
Я думаю, что гораздо большей проблемой было бы иметь хорошие примеры тестовых случаев. Их создание и поддержка обычно не легки и занимают много времени. Особенно, если вы хотите иметь возможность выполнять их автоматически, что в данном случае было бы крайне необходимо.