Нет. Есть совершенно техничный расчет. Нагрузка на парсинг json - ненулевая. И в тайм-критичных
отраслях его имеет смысл заменять на бинарный протокол.

Сюда-же до кучи хранение BLOBS. В json его оборачивают в bas64 а это не очень экономно.

Кроме того Protobuf заявлен как толерантный к last/big endian а это очень важно для
когда бинарные месседжи должны одинаково представлять целые числа на экзотических
железяках.

До того как мы начнем обсуждать микро-секунды я дам парочку цифр.

Свет в вакууме проходит расстояние 30 см за 1 наносекунду.

Можно прикинуть что оперативная память с быстрым доступом работающая на нано-секундах (6нс)
должна учитывать компоновку на материнке так чтобы ФИЗИЧЕСКОЕ расстояние электронных
дорожек на монтаже было КОРОТКИМ. Тем более что свет (электромагнитная волна) здесь привен
просто как близкая аналогия к электричеству в металле).

Поэтому когда мы говорим о микро-секундах (это величина на 3 порядка (*1000)) больше чем световой отрезок
о котором я говорил то надо понимать что бесполезно оптимизировать траекторию света если
у нас есть задержки другого порядка. Задержка в 1 микро-секунду - это уже 1000 циклов ожиданя
света. Тоесть несоизмеримо долго.


Далее.

И чтобы мерять микро-секунды у нас в коде не должно быть величин на 3 порядка больше. К таким
величинам я отношу
- Seek time физического блока жесткого диска (HDD) 15 милисекунд (почти на всех моих HDD с небольшим отклонением)
- Ping time до Нью-ЙОрка был порядка 120 мс.
- Время JIT компилляции. Здесь я точно не уверен но вангую больше 100 мс. Кроме того это сильно
зависит от complexity самого java-метода.

И если у нас в коде вдруг (!) внезапно активировался JIT компиллятр и вставил задержку в 200 мс
то измерение микро-секунд вообще не имеет никакого смысла. Мы внесли погрешность
настолько большую что доверять измеряемым цифрам в принципе невозможно.

Какой выход? Делать очень много измерений. И усреднять. По аналогии с JMeter для веба и JMH для хардкорных
функций которые должны быть на пике скорости.

Код который привел Вадя - этим условиям не удовлетворяет. Он не собирает 1 callback и делает по нему выводы.

Надо сделать хотя-бы 100 * 1000 каллбеков чтобы скопменсировать эффект JIT. Или делать 1000 циклов прогрева
без измерений и еще 100 уже по горячему коду.

Вадя должен это увидеть глазами.

Я считаю что тема топика - не троллить и поносить Вадю. А разъяснить.

Нужно не бесится а измерять. И браузер показывает распределение таймингов. И на back-end можно внедрить точный сбор метрик.

Микро- суффикс означает одна миллионная. Это так. Замечание.

Твоя инициатива похвальна. Но методы - судорожные и гипертрофированные.
Нет смысла оптимизировать конкатенации строк когда у тебя
- кривой nginx, который не настроен чтоб выполнять свои функции.
- Не настроен и не используется Infinispan/EhCache.
- плохо ведет себя клиент (использует 3g модем или браузер в телевизоре смарт-тв)

Это всё нагромождение технического долга должно быть собрано в брейншторм. Проанализировано.
И по каждому пункту нужны цифры.

Веб отрасль достаточно старая сегодня чтобы выработать best-practices. И 99.9% этих практик
лежат не в плоскости строкового билдера. Вот я нигде. Ни на одном проекте не видел
чтобы ботл-неком были сборки строк. Практически везде были совсем другие поинты.

Ты пришел в топик с доказательством того что твоё улучшение значимо? И оказывает эффект?

Нет. Ты просто нашёл забавную возможность сцеплять строки в БД.

Но к реальной оптимизации это не имеет никакого отношения. Смотри свои цифры.
Меряй. Приводи скриншоты временных диаграм браузера. Собирай кумулятивные цифры
на back-end.

Я тебе привел список поинтов на что обратить внимание когда пользователь долго ждет.
Это - архитектурные поинты. И они обеспечат тебе 80% эффекта. Я так думаю. Ты конечно
можешь упасть в свою тяжелую... похожую на прокрастинацию, идею о том что надо срочно
искать StringBuilder или билдить строки в БД но я готов спорить на бутылку Виски что
твоё направление поисков - неэффективно. И ты зря тратишь время и деньги заказчика.

И другой разработчик на твоем проекте. Если послушает моих советов - быстро пофиксит
этот NFR и все будут счастливы. А ты будешь - посрамлён.

Реальный пример - это диагностика проблемы в твоём приложении.