Оптимизация программного кода — задача, к которой каждый разработчик относится с большой осторожностью и уважением. Особенно когда речь заходит о системах с высоким уровнем нагрузки, где даже доли процента выигрыша в производительности оборачиваются значительной экономией ресурсов. Но бывает так, что вложенные усилия и время не дают ожидаемого результата из-за ошибки, которая на первый взгляд кажется простой и малозначительной. В своей практике мне пришлось столкнуться с ситуацией, когда недели работы по ручной оптимизации ассемблера оказались практически бесполезными, поскольку все тестирование велось на случайных данных, далеких от реального использования. Данная история — хороший пример того, насколько важно правильно подходить к выбору тестового окружения и что может произойти, когда игнорируются реальные условия эксплуатации программного обеспечения.
Моя задача заключалась в оптимизации Java-кода, отвечающего за сериализацию данных на крупном распределенном вычислительном кластере. Этот кластер насчитывал сотни тысяч машин, и даже минимальное повышение эффективности кода, например на 0.5%, приносило ощутимую экономию ресурсов, превосходящую стоимость рабочей силы. Было известно, что база кода уже очень оптимизирована: разработчики избегали лишних аллокаций памяти, минимизировали использование объектов, чтобы не создавать лишнюю нагрузку на сборщик мусора, и тщательно профилировали узкие места. Одна из таких точек для оптимизации — кодирование целочисленных данных с помощью VarInt, а именно формата ULEB128, дающего компактное представление чисел, которое широко применяется в различных форматах, таких как Google Protobuf, Apache Thrift, WASM и других.
Этот формат позволяет кодировать числа с использованием переменного количества байт, отдавая предпочтение меньшему количеству байт для маленьких значений. В теории, ручная оптимизация такого алгоритма на ассемблере с применением современных инструкций SIMD должна приносить выигрыш в производительности. Вместе с командой мы приступили к разработке высокопроизводительного варианта VarInt кодировщика. Использовались новейшие инструкции процессора, в том числе BMI2, для эффективного распределения бит по необходимым позициям, а также AVX2 для параллельной обработки данных и минимизации ветвлений в коде. Оптимизированный алгоритм в несколько раз превосходил по скорости существующую реализацию на Java при тестах, выполненных на огромном количестве случайных чисел.
Результаты выглядели впечатляющими: четырехкратное ускорение являлось значительным достижением. Однако проблема обнаружилась, когда мы попытались внедрить новшество в продакшен. Несмотря на очевидный выигрыш в синтетических тестах, реальная производительность приложения практически не изменилась. Мы провели дополнительные наблюдения и пришли к выводу, что причина скрывается в характеристиках входных данных. Генерируя случайные числа в диапазоне 64-битных значений, мы фактически создавали нагрузки, характерные для наихудшего сценария с точки зрения длины VarInt.
Доля «длинных» чисел, требующих максимального количества байт для кодирования, была чрезмерно высока в тестах, тогда как на деле большинство данных, с которыми работает система, были относительно маленькими числами, укладывающимися в одни-двух байт. Данная диспропорция в распределении чисел изменила всю ситуацю с эффективностью кода. Видимо, Java реализация была достаточно оптимизирована под короткие числа, в то время как ассемблерный вариант выгодно показывал себя именно на длинных, редко встречающихся значениях — тех, которых в реальной нагрузке было мало. Тесты же на случайных данных непропорционально отражали именно эти случаи, вводя в заблуждение относительно реального выигрыша от оптимизации. По итогам было принято решение отказаться от внедрения оптимизированного варианта на ассемблере.
Тем не менее, этот опыт не прошел бесследно. Он научил меня важности правильного выбора тестовых данных и критически важной роли адекватного профилирования реальных сценариев использования. Просто создавать и запускать бенчмарки на случайных, искусственных наборах данных недостаточно при принятии значимых изменений. Нужна глубокая аналитика, понимание распределения входных значений и моделирование реальных условий, в которых будет работать приложение. Эта история имеет несколько важных уроков для любого разработчика и инженера в мире высоких технологий.
Во-первых, оптимизация никогда не должна строиться на абстрактных и неподходящих тестах. Во-вторых, стоит внимательно анализировать, представляют ли используемые данные реальные типы нагрузки и разнообразие случаев на практике. Без этого быстро можно потратить значительные ресурсы на улучшения, которые в реальных условиях никакого эффекта не принесут. Кроме того, опыт показал, что сложные и продвинутые технологии — такие как SIMD-оптимизации и кастомные JIT-компиляции — хороши для учебных и экспериментальных задач, но далеко не всегда оправдывают себя в продуктивных системах, где важна общая сбалансированность и время выполнения. В случае, если система работает в пределах небольшой части значения или с определённым преобладающим паттерном данных, базовые решения на высокоуровневом языке программирования зачастую будут предпочтительнее за счёт простоты, масштабируемости и поддержки.
