Комментарии 16
А содержание метода, который оптимизировали, большая тайна?
/бубнит Лучше бы нормальные bitrix модули для СБП и интернет-эквайринга своего же сделали...
Замеряй и ускоряй: как мы сократили время вызова метода в Java-коде в 16 раз - э... действительно: как?
даже нет (голосом Коляна): да как так то?
ChatGPT что ли?
Предлагаю переименовать, пока не поздно:
Суровые трудовые будни или для чего в Сбере применяют System.nanotime() - вот так было бы пожалуй информативнее.
В одном из проектов Platform V DataSpace вызов метода занимал очень много времени.
Что занимало много времени? Вызов? Может метод долго работал, а не вызывался долго?
Для оптимизации нужно было оценить точную длительность работы метода.
Для оптимизации, очевидно, нужно уменьшить время работы метода. А еще лучше перестать его вызывать несколько раз. А оценить точную длительность работы метода нужно для того, чтобы решить, нужно ли его вообще менять и если да, то чтобы оценить результат доработки.
Можно подключить трассировки, например, elastic APM и там увидеть все задержки в боевых условиях вместо изобретения своих методов замера и графиков.
Что мешало включить профайлинг во время выполнения запроса и посмотреть самый дорогой вызов? Или хотя бы здесь выложить flame-graph с вызовами.
Что хоть тормозило, наносекунды? А зачем такая точность, особенно, если я понимаю, тормозит. У вас же там секунды (а не микросекунды) ожиданий.
Нда ... Просто 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()и пару серверов отправили на склад? Чего в итоге получилось-то?
Замеряй и ускоряй: как мы сократили время вызова метода в Java-коде в 16 раз