Почему вы использовали самописную библиотеку вместо готовой?

В моем опыте на проекте по обработке финансовых данных в реальном времени мы приняли решение разработать собственную библиотеку сериализации бинарных протоколов. Существующие решения, такие как Protocol Buffers или FlatBuffers, не полностью удовлетворяли нашим ключевым требованиям.

Причины и обоснование:

1. Экстремальные требования к производительности и нулевым накладным расходам: Наш протокол должен был обрабатывать десятки тысяч сообщений в секунду с минимальной задержкой. Готовые библиотеки добавляли overhead на динамическое выделение памяти, виртуальные таблицы и избыточные проверки.

   • Наше решение: Мы использовали шаблонную метапрограмму на C++17 для генерации кода сериализации/десериализации на этапе компиляции.

     // Пример идеи (упрощенно): структура описывает сообщение.
     struct TradeMessage {
     int64_t timestamp;
     double price;
     int32_t volume;
     char symbol[8];
     };
     // Специализированный шаблонный сериализатор генерирует оптимальный код.
     auto bytes = BinarySerializer<TradeMessage>::pack(trade);

2. Специфичный, жестко заданный формат данных: Мы работали с legacy-системой, которая использовала проприетарный бинарный формат с особым порядком байт и упаковкой полей. Интеграция сторонней библиотеки потребовала бы слоя адаптера, усложняющего систему и снижающего производительность.

3. Минимизация зависимостей: Проект должен был развертываться в изолированной среде с жесткими требованиями к безопасности. Добавление крупной сторонней зависимости увеличивало бы поверхность атаки и сложность обновлений.

4. Полный контроль и оптимизация под железо: Мы смогли использовать специфичные инструкции процессора (например, SSE для копирования блоков памяти) и оптимизировать алгоритмы под наши паттерны доступа к данным.

Компромиссы и вывод: Разработка собственной библиотеки — это значительные затраты на проектирование, реализацию и, что критично, тестирование. Мы оправдали эти затраты, потому что выигрыш в производительности и предсказуемости был ключевым для бизнес-логики продукта. В большинстве же случаев я предпочитаю использовать проверенные, поддерживаемые сообществом решения, такие как Boost или библиотеки из STL.