Как стать автором
Обновить

Замеряй и ускоряй: как мы сократили время вызова метода в Java-коде в 16 раз

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров7.5K
Всего голосов 33: ↑13 и ↓20-1
Комментарии16

Комментарии 16

А содержание метода, который оптимизировали, большая тайна?

У нас есть такие приборы!

/бубнит Лучше бы нормальные bitrix модули для СБП и интернет-эквайринга своего же сделали...

Работает, не трогай! (Сбер)

Замеряй и ускоряй: как мы сократили время вызова метода в Java-коде в 16 раз - э... действительно: как?
даже нет (голосом Коляна): да как так то?
ChatGPT что ли?

Предлагаю переименовать, пока не поздно:

Суровые трудовые будни или для чего в Сбере применяют System.nanotime() - вот так было бы пожалуй информативнее.

В одном из проектов Platform V DataSpace вызов метода занимал очень много времени.

Что занимало много времени? Вызов? Может метод долго работал, а не вызывался долго?

Для оптимизации нужно было оценить точную длительность работы метода. 

Для оптимизации, очевидно, нужно уменьшить время работы метода. А еще лучше перестать его вызывать несколько раз. А оценить точную длительность работы метода нужно для того, чтобы решить, нужно ли его вообще менять и если да, то чтобы оценить результат доработки.

Можно подключить трассировки, например, elastic APM и там увидеть все задержки в боевых условиях вместо изобретения своих методов замера и графиков.

Что мешало включить профайлинг во время выполнения запроса и посмотреть самый дорогой вызов? Или хотя бы здесь выложить flame-graph с вызовами.

Что хоть тормозило, наносекунды? А зачем такая точность, особенно, если я понимаю, тормозит. У вас же там секунды (а не микросекунды) ожиданий.

Timestamp у них растягивался, написано же.

Я читал тот участок, но не понял как растягивался. Вдоль или в ширину? А вы поняли?

Нда ... Просто Hotspot сгенерил нативную версию метода и выполнил ее быстрее. Поищите старый доклад Валерия Иванова из Oracle про динамическую компиляцию.

Из статьи непонятно вообще ничего. Что вы оптимизировали, как, зачем, почему? Что там за требования к процессу такие, что «вместо» JMH вам пришлось тащить что-то ещё? И зачем вообще JMH, если вы какую-то энрепрайз штуку измеряете? Это же тул для _микро_бенчмарков.

Void checkTime(){
Long oldTime = System.nanoTime();
work();
return System.nanoTime() – oldTime;
}


Вот прямо вот так, с Void и Long?
Примитивные типы у вас из-за санкций закончились?

Зря я относился к заявлению Грефа про «дефицит сотрудников уже компенсирован» со скепсисом. На все 146% компенсировали.

В нашем случае самописные бенчмарки помогли серьёзно сократить длительность вызова System.nanoTime()

Так вы JVM разрабатываете или всё же вашу «Платформу пятой колонны»?
Оптимизация методов стандартной библиотеки и соответствующих им intrinsics это область ответственности разработчиков JVM. Пользователь тут разве что JVM прогреть может.

Я так и не понял, что было и как стало, каким образом и что рефачили. Убрали static и синхронизацию метода? Spring Bean Singleton перестал хранить состояние или быть Singleton?

Такое ощущение, что корпоративный аккаунт Сбера угнали :) В Сбере не делают ревью перед публикацией в корпоративном аккаунте? Вообще не понятно о чем, к чему и с какой целью написано, а название интриговало... Реально похоже на что-то сгенерированное chatgpt или студентом.

Забавно. Как раз сегодня с коллегами развлекались и оптимизировали вызов некоего метода в 45 раз (1600 ns до 35 ns). Круто ж?

Но в итоге посчитали, что чтоб улучшить время обработки сообщения хотя бы на 1 миллисекунду, нужно чтоб было сделано минимум 600 вызовов, а их при обработке каждого конкретного сообщения, вроде бы и нет, значит эффект только в общей пропускной способности приложения и то мне факт.

Я к чему - совсем не важно, что какой-то метод оптимизирован на пару порядков, важно, какой это эффект дало, может ребята убрали этот nanoTime()и пару серверов отправили на склад? Чего в итоге получилось-то?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий