HikariCP — самый быстрый пул соединений на java

потому что альтернативный вариант без исключения затормаживает

Речь о

if (condition) return error_core;

?

И что за библиотека такая, где надо волноваться о таких мелочах?

Балансировка 70 тысяч запросов в секунду на HighLoad++

Чувствую себя неудачником со своими 11к рек-сек.

HikariCP — самый быстрый пул соединений на java

Ну почему же, вдруг Вы укажете на некую лже-оптимизацию и это ускорит хикари. Все пользователи от этого выиграют.

HikariCP — самый быстрый пул соединений на java

А Вы можете в тикет ответить на гитхабе? Мне как-то не хочеться постоянно проксировать ответы =).

HikariCP — самый быстрый пул соединений на java

Ну вроде нет — github.com/brettwooldridge/HikariCP/issues/464

HikariCP — самый быстрый пул соединений на java

Автор хикари ответил Вам. И утверждает что одноклассники в 8 раз медленее, а не быстрее. К сожалению у меня нету приглоса, так что вот ответ github.com/brettwooldridge/HikariCP/issues/464#issuecomment-149141231

HikariCP — самый быстрый пул соединений на java

I benchmarked both ways when the code was written. This is faster 95% of the time. It only incurs overhead when the list is expanded — but that is a slow path anyway because of the memory copy.

github.com/brettwooldridge/HikariCP/issues/462

HikariCP — самый быстрый пул соединений на java

и тогда заголовок статьи про «самый быстрый пул соединений» — тем более надувательство.

Ну на момент написания статьи Вашего кода даже не было в репозитории. Так что — нет. Не надувательство.

HikariCP — самый быстрый пул соединений на java

как динамическое создание класса, с помощью javassist ускоряет работу 34 инструкций перед 35 инструкциями.

А как эти 2 вещи вообще связаны =)?

HikariCP — самый быстрый пул соединений на java

Давайте бенчмарки. А вдруг там ошибка =)?

HikariCP — самый быстрый пул соединений на java

JVM и так отлично оптимизирует StringBuilder.

String s = «aaa...»; //100500 chars
new StringBuilder().append(«1»).append(s).toString();

компилятор заоптимайзит в new char[1+s.length]. Опция — OptimizeStringConcat. Так что прирост очень сомнителен.

HikariCP — самый быстрый пул соединений на java

Я не говорил, что не JVM проверяет диапозоны массива.

HikariCP — самый быстрый пул соединений на java

Из ссылки выше:

if (index >= arr.length) {
break;
}

Речь об этом условии. Я так понимаю что автор Хикари избегает его. Так как выбрасывание эксепшена за жизнь пула происходит раз-два и все.

IoT cloud на Netty или 10к рек-сек на ядро

Кстати, книга уже устарела. В нетти много чего поменялось с тех пор. Ну и на некоторые вопросы там всеравно нету ответов =). Хотя судя по всему это пофиксят в следующей книге.

HikariCP — самый быстрый пул соединений на java

Ок, спасибо за развернутый ответ. Думаю автор просто не усложнял в контексте той статьи.

HikariCP — самый быстрый пул соединений на java

Стоиомсть try не важна, если пул живет месяцами и за этот месяц try вызывается пару раз для увеличения списка. В то время как add/remove выполняются каждую секунду сотни раз в случае нагруженности пула. Но это лишь мое предположение.

HikariCP — самый быстрый пул соединений на java

Ну я так понял, что цель всей той колбасы просто избежать условия
if (size < elements.length)

Вообще я задал вопрос автору. Так что подождем. Я так не оптимизирую, если что =).

IoT cloud на Netty или 10к рек-сек на ядро

Я ее прочитал =).

HikariCP — самый быстрый пул соединений на java

лимит задаётся совсем другими параметрами JVM

Так в статье и не про это. Просто мимоходом упоминается, что есть вот такая штука длина метода в байткодах для инлайнинга, дефолтная она 35 байткодов. Может Вас смутило слово «лимит»? Окей извиняюсь за плохой перевод.

Заодно и развеем миф invokestatic vs. invokevirtual:

А в статье не говорится что вызов invokestatic быстрее invokevirtual. Там говорится, что у JIT большей вохможностей по оптимизации в случае invokestatic.

HikariCP — самый быстрый пул соединений на java

это вовсе не лимит инлайнинга

А что же?