Профилировать, даже на начальных этапах, проще с помощью async-profiler (в режиме jfr с конвертацией в heatmap). Это даст наглядное представление о происходящем, поможет реально разобраться в том, на что уходит время и как коллекции устроены.
Да даже когда/если появится возможность указывать пул, я бы всё равно за пределами пет-проджектов предпочел воздержаться. Тяжело отлаживать, тяжело предсказывать производительность, легко сломать неловким движением. Steam API делался в спешке и получился предельно чужеродным для языка.
Нет, в данной ситуации я бы использовал wall-profile. Ключевых отличий для нашего случая как минимум два:
Async-profiler может показывать граф вызовов вплоть до ядра, а не только java-часть.
Возможность визуализации в виде хитмапа с возможностью дальнейшего анализа и сравнения флеймграфов за произвольный период.
Также в некоторых случаях async-profiler показывает значительно более высокую точность профиля, т.к. проектировался как раз в т.ч. для патологических corner-case'ов.
В любом случае, главная часть моего утверждения: специализированный инструмент (профайлер) лучше ручных дампов потоков.
Такие оценки напоминают мне прогнозы по производительности JS после выхода V8. Все кто реально знает, как это работает, уже тогда понимали, что дальше только асимптотические улучшения. Зато любители строить аппроксимации и говорить что-то вроде "замедление темпа не означает изменения направления" уверенно предрекали JS'у производительность выше условно взятого С++.
Не буду подавать идей товарищу майору, но и с этой техникой есть способы борьбы на стороне товарища майора, при наличии мощностей, компетенции и желания. Хочется верить, что чего-то из этого перечня товарищу не хватит.
Я полностью согласен с посылом, но для корректности стоит всё-таки добавить, что эти ИИ не имели (в процессе работы по крайней мере) доступа к опенсорсу. Т.е. обгадились вполне себе самостоятельно.
Обычно, пусть и не всегда, можно разобраться по git blame + номера тасок. Это долго и муторно, но я с разбега не могу вспомнить, чтобы мне не удалось докопаться до причинности (уверен, что такое бывало).
В большинстве случаев (не всегда, иногда это невозможно), когда моя рука тянется написать комментарий, я просто переписываю код, чтобы это было не нужно.
Проблема в том, что писать код было всегда проще, чем читать/проверять. LLM это никак не поменяло, стало только хуже.
Когда код пишешь - он в каком-то смысле уже немного проверен. Тем, что ты к нему как-то пришел, у тебя были какие-то причины написать, так, а не эдак. Когда код читаешь - очень сложно видеть за рамками видимой логичности. Нет, конечно, существуют люди, которые способны читать код так, будто бы его пишут. Я даже знаю... Одного.
У меня же, чтобы прочитать чужой код и быть уверенным, что он работает так, как ожидается, что тесты корректны и достаточны, что он вообще решает поставленную задачу, уходит больше времени, чем написать его самому. И делаю я это обычно для обучения, чтобы человек после десятка-двух моих ревью понял некоторые принципы и начал вызывать больше доверия, требуя меньше внимания к его коду.
Netty это и есть что-то типа nginx.
Профилировать, даже на начальных этапах, проще с помощью async-profiler (в режиме jfr с конвертацией в heatmap). Это даст наглядное представление о происходящем, поможет реально разобраться в том, на что уходит время и как коллекции устроены.
Да даже когда/если появится возможность указывать пул, я бы всё равно за пределами пет-проджектов предпочел воздержаться. Тяжело отлаживать, тяжело предсказывать производительность, легко сломать неловким движением. Steam API делался в спешке и получился предельно чужеродным для языка.
Ещё в копилку: связанные списки убивают GC, т.к. нужно не только обойти кучу указателей, но это ещё и не параллелится.
Нет, в данной ситуации я бы использовал wall-profile. Ключевых отличий для нашего случая как минимум два:
Async-profiler может показывать граф вызовов вплоть до ядра, а не только java-часть.
Возможность визуализации в виде хитмапа с возможностью дальнейшего анализа и сравнения флеймграфов за произвольный период.
Также в некоторых случаях async-profiler показывает значительно более высокую точность профиля, т.к. проектировался как раз в т.ч. для патологических corner-case'ов.
В любом случае, главная часть моего утверждения: специализированный инструмент (профайлер) лучше ручных дампов потоков.
Рекомендую async-profiler вместо дампа потоков, наглядно будет видно всё происходящее без необходимости применять интеллект.
А оно снизилось отрицательно просто.
А можно пожалуйста не надо?
Такие оценки напоминают мне прогнозы по производительности JS после выхода V8. Все кто реально знает, как это работает, уже тогда понимали, что дальше только асимптотические улучшения. Зато любители строить аппроксимации и говорить что-то вроде "замедление темпа не означает изменения направления" уверенно предрекали JS'у производительность выше условно взятого С++.
Надо срочно переставить местами койки!
Не буду подавать идей товарищу майору, но и с этой техникой есть способы борьбы на стороне товарища майора, при наличии мощностей, компетенции и желания. Хочется верить, что чего-то из этого перечня товарищу не хватит.
Да.
Я полностью согласен с посылом, но для корректности стоит всё-таки добавить, что эти ИИ не имели (в процессе работы по крайней мере) доступа к опенсорсу. Т.е. обгадились вполне себе самостоятельно.
Обычно, пусть и не всегда, можно разобраться по git blame + номера тасок. Это долго и муторно, но я с разбега не могу вспомнить, чтобы мне не удалось докопаться до причинности (уверен, что такое бывало).
В большинстве случаев (не всегда, иногда это невозможно), когда моя рука тянется написать комментарий, я просто переписываю код, чтобы это было не нужно.
Тем не менее, большинство решает действительно очень простые задачи, но щеки (процессы) раздувают так, будто бы они очень сложные.
Ну я тесты пишу как раз чтобы тестировать. Для меня это быстрее и проще, а то, что после меня остаётся артефакт - это приятный бонус.
Одно другого не отменяет: да, будет всё ещё ужас, но есть (не очень большой) шанс, что уже не ужас-ужас-ужас.
Проблема в том, что писать код было всегда проще, чем читать/проверять. LLM это никак не поменяло, стало только хуже.
Когда код пишешь - он в каком-то смысле уже немного проверен. Тем, что ты к нему как-то пришел, у тебя были какие-то причины написать, так, а не эдак. Когда код читаешь - очень сложно видеть за рамками видимой логичности. Нет, конечно, существуют люди, которые способны читать код так, будто бы его пишут. Я даже знаю... Одного.
У меня же, чтобы прочитать чужой код и быть уверенным, что он работает так, как ожидается, что тесты корректны и достаточны, что он вообще решает поставленную задачу, уходит больше времени, чем написать его самому. И делаю я это обычно для обучения, чтобы человек после десятка-двух моих ревью понял некоторые принципы и начал вызывать больше доверия, требуя меньше внимания к его коду.
Да, теперь намного понятнее, автору стоило вычитать текст, столько опечаток.