Комментарии 10
Иными словами нельзя просто так взять и выбросить создание массива, т. к согласно спецификации исполнение обязано бросить NegativeArraySizeException и ничего мы с этим поделать не можем:
Ну или код по созданию массива можно заменить на код, который проверяет длину и кидает исключение, если она отрицательная. Это небольшой оверхед, но это всё равно намного лучше, чем создавать ненужный массив в куче.
Думаю, исполнение именно так и делает, по крайней мере в Граале.
Грааль везде проверки расставляет, и в случае их нарушения фолбэчится в неоптимизированный код. В принципе, c2 тоже так делает, но у него просто не хватает знаний о внутренностях некоторых языковых конструкций байткода. Например, я не могу назвать случаи, когда c2 выкинул бы лишнее выделение памяти, когда можно было бы обойтись без него (тот же varargs). Он умеет это делать только в вручную написанных интринсиках типа конкатенации строк.
Мораль сей басни такова: ваш гениальный патч могут зарезать на ревью просто потому, что не увидят в нём особой ценности. Ну да, есть повторяющийся код, но он никому особо не мешает, так что пусть живёт.
Дело не совсем в этом, тебе же сказали. Если делаешь метод в Arrays, нужны как минимум специализации для int/long/double, а желательно и для byte/boolean/short/char/float. В итоге имеем девять методов. И логично иметь версии с диапазоном поиска. Вот уже 18 методов. И ещё lastIndexOf — итого 36. Это уже серьёзная заявка. Люди надеются на светлое будущее и специализацию дженериков, когда можно будет обойтись четырьмя методами. Поэтому не хотят плодить новый код, связанный с речной специализацией. Только когда это будет — неясно.
Это уже серьёзная заявка.
Это можно парировать наличием 6 методов EnumSet.of() и 12 (!) методов List.of() и ещё стольких же у Map.of(). И всё только для того, чтобы варарги не использовать ну и с прицелом на средний размер списка/словаря.
Так что тут палка о двух концах, имхо. Тем более, что в случае с Arrays код получается довольно однотипным — только типы меняй. И раздувание класса Arrays вполне себе возмещается ужатием прочих коллекций на основе массива, ведь мы не просто добавляем методы — мы ещё и убираем их же тела из коллекций.
Совсем забыл, Arrays.sort() вполне себе используется из COWList-a, ArrayList-a и т.д. и там тоже есть все методы для всех примитивов и ссылок + отдельные методы для параллельной сортировки и сортировки слиянием.
С ArrayList у тебя стандартная проблема бенчмарк-энтузиаста, кстати. Ты увидел кейс, который в твоей практике случается часто, заточил библиотеку под этот кейс и написал бенчмарк тоже под этот кейс. Почему не потестировать другие кейсы? Если туда HashSet прилетает, сколько съедает лишняя проверка? А если разные реализации прилетают, например emptyList/singletonList/ArrayList/unmodifiableList в равной пропорции (вполне жизненная ситуация)? Насколько ускорится или замедлится каждый случай? Тело метода стало больше, влияет ли это на решения об инлайнинге?
Я не к тому, что твоя идея плоха. Она может и хороша. Я к тому, что надо критически смотреть на свои гениальные идеи.
Ну, пример с ArrayList-ом, справедливости ради, не мой — его предложил Стив Грёгер.
По поводу остального я согласен, что один случай не показатель. Точно так же я когда-то хотел предложить улучшение сортировки: если массив состоит всего лишь из двух элементов, то их можно просто переставить (если первый больше второго) или оставить всё как есть (в противоположном случае). Оказалось, что лишние проверки будут бить по всем остальным случаям (в массиве более 2 элементов).
Я к тому, что надо критически смотреть на свои гениальные идеи.
Для этого и существует сообщество — чтобы бить советской железной линейкой по излишне шаловливым рукам. Сам всего в голове не удержишь, тем более могут вылезти грабли о которых ты даже не подозреваешь.
Как-нибудь напишу, как я пробовал TreeMap подлатать: вроде всё идеально ложится, 150 строк кода можно выкинуть не поломав ни единого теста, производительность растёт, ну красота же! А оказалось, что если взять TreeMap до моих изменений, сериализовать, записать в файл, а потом превратить обратно в TreeMap (но уже с моими изменениями) то будет НПЕ :)
Ничто не предвещало беды...
Не все патчи одинаково полезны