Вернувшись с JPoint 2017, где с огромнейшим удовольствием пообщался с большим числом мегакрутых программистов решил надеть шляпу и покопаться в разного рода оптимизациях.  JPoint 2017 открывался с мега пленарного доклада Алексея Шипилёва, который он анонсировал ёщё в октябре 2016 на Joker — тогда я смотрел его online и проникся Кривой им Ш:  И если с зелёной и красной зоной как-то более-менее ясно-понятно, то вот с границей зеленой-жёлтой не всё так очевидно — что это? можно пример ? Начнём с эпичного срача вопроса — что быстрее — ручной джедайский меч или расово верный System.arraycopy. На данный момент векторизация и intrinsic делают оба варианта равнозначными — вопрос вкусовых предпочтений.  Есть коллекция, например, строк, и хотим получить массив.  Лучшее (враг хорошего) решение: Arrays of Wisdom of the Ancients учит, что новое это хорошо забытое старое Раньше (когда деревья были высокими) при создании экземпляра ArrayList / HashMap / etc внутри создавался массив с начальным размером ( 10 для ArrayList, 0x10 для HashMap ).  Другое дело, когда вы заранее знали, какое количество элементов вы собираетесь положить в коллекцию — опытные джедаи создают сразу что-то типа сразу запихиваете свои values и счастье — никаких паразитных аллокаций от 10 элементов до вашей цели.  Но что, если самих значений ещё нет — с null возиться не хочется, но знаем, что будет не больше, например, трёх?  И погнали — профит в 7 сэкономленных ячеек на каждый такой список ( ~7 * 16 байт / список ), который когда-то да будет заполнен. Optimize empty HashMap and ArrayList коммит в openjdk — теперь все ArrayList / HashMap, созданные от конструктора по-умолчанию держат пустую static заглушку — и первое же добавление создаст массив на 10 элементов (для ArrayList, 16 для HashMap), тогда как new ArrayList( int ) создаёт массив энергично и сразу. Что знают джедаи про регулярные выражения?
 Компилировать regexp каждый раз — дорого, опытные падаваны делают вместо stringValue.split(regexp) что-то типа Профит в том, что шаблон не компилируется каждый раз.  Lightweight implementation of String.split for simple use case Если у вас односимвольный разделитель — именно разделитель типа ( пробел ) или , ( запятая ), а не спец. символ регулярного выражения типа . ( точка ) — то никакое регулярное выражение даже и близко не создаётся.  Я не буду даже говорить про код, который явно пахнет типа пользы от него никакой — зато читаемость никакая.  Можно очень кропотливо подбирать размеры кучи и прочие XX-флаги — но со временем, когда в код проекта влито ещё 1000 и 1 одна бизнес фича все эти флаги могут более, чем запросто не приносить желаемого результата быстроты. Считайте они протухли. Если ваш проект жив и процветает, а вас раз в сто-двести лет просят устроить перформанс (хотя танцы голым на пьяных столах тоже перформанс, но я немного о другом ) — то появляются всякого рода оптимизации, и не исключено, что из той самой жёлтой зоны, которые по истечению срока годности начинают не просто пахнуть, но и делать обратную задачу от изначальной — тормозить приложение.  Надежды нет, что анализаторы типа PMD, или ваша любимая IDE имеют актуальные рекомендации именно для той версии java, на которой вы запускаеть в PROD ==> Проводите ревизию магических приёмов знаний.