Наиболее эффективный формат проводов для кода GHCJS через веб-сокеты
Я работаю над приложением на Haskell, работающем в браузере, скомпилированном с GHCJS, который связывается с сервером, также написанным на Haskell, через веб-сокеты. Обе программы используют одно и то же определение типа данных на Haskell, и мне просто нужно выбрать формат сериализации.
На данный момент для простоты программа работает на Read а также Show, который работает, но, очевидно, не идеально.
С другой стороны, неясно, являются ли обычные претенденты на быструю сериализацию, такие как cereal библиотека, на которой работают ByteStrings на самом деле будут эффективными в GHCJS. Кроме того, API GHCJS, кажется, затрудняет ByteStrings взаимодействовать с двоичным Blob тип, который обеспечивают привязки JavaScript к Websockets.
Генерация общего кода (с использованием GHC.Generics) было бы здорово.
Кто-нибудь решил эту проблему раньше? Возможно, даже тестировали различные варианты сериализации на GHCJS?
1 ответ
Мы искали быструю библиотеку сериализаторов / десериализаторов в Haskell для хранения данных в кеше Reddis в прошлом году, и в итоге мы использовали ProtoBuf! Это было отчасти потому, что у нас уже была реализация ProtoBuf всех объектов, которые мы хотели сериализовать, но производительность была также намного лучше по сравнению с зерновыми / двоичными файлами. К тому времени магазина еще не было.
Размер и скорость сериализации / десериализации очень сильно зависит от ваших данных. Например, если у вас много маленьких (скажем, в диапазоне от 1 до 100) 64-разрядных чисел, protobuf (из-за его базового 128-вариантного кодирования) или даже JSON могут быть более эффективными, чем зерновые или двоичные (которые, я думаю, используют фиксированные размер для чисел независимо от их значений).
Существует также Typed-Wire, который позволяет выполнять сериализацию на нескольких языках, но я думаю, что он использует JSON в качестве базовой реализации.
У меня нет опыта работы с GHCJS, но я бы рекомендовал попробовать store первый. Просто убедитесь, что клиент и сервер не имеют небольшой / большой несовместимости с прямым порядком байтов.