еще одна библиотека сериализации для С++. проживает тут.
YAS был создан как замена boost.serialization из-за непозволительно низкой скорости сериализации.
бинарная сериализация YAS в 3-8 раз быстрее.
текстовая сериализация YAS в 2-3 раза быстрее.
в планах — реализация JSON(сделано) и BSON.
YAS является 'header only' библиотекой. YAS не зависит от сторонних библиотек или от boost.
YAS предоставляет сериализацию как в/из буфер, так и в/из файл.
YAS может использоваться как на 32ух, так и на 64ех битной архитектурах. при этом, архивы сериализации полностью переносимы в обоих направлениях.
YAS требует от компилятора поддержки C++11.
задачи, планируемые к выполнению, располагаются в следующем порядке, в порядке убывания:
1. дореализовать тест переносимости архивов сериализации между 32 и 64-бит архивами.
2. реализовать тест совместимости YAS и boost.serialization.
3. добавление поддержки rvalue-refs & move-semantics.
4. переход на использование ADL вместо SFINAE.
5. реализовать возможность назначить используемый фильтр.
6. реализовать сжатие архивов "налету".
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>еще одна библиотека сериализации для С++. проживает тут.
X>YAS был создан как замена boost.serialization из-за непозволительно
1. IO был отделен от архивов.
теперь у пользователей есть возможность реализовать/использовать свои собственные istream/ostream классы.
для istream классов требованием является наличие метода 'std::size_t read(void *ptr, std::size_t size)'
для ostream классов — 'std::size_t write(const void *ptr, std::size_t size)'
эта возможность была реализована для того, чтоб пользователи могли реализовать максимально эффективные стратегии, такие как запись в сокет или в 'interprocess memory' без использования промежуточных буферов/копирования.
2. бинарные архивы по умолчанию 'endian independent'. это означает, что сериализовав данные в бинарный архив на x86-хосте, вы сможете десериализовать его на таких архитектурах как SPARC/PowerPC/ARM.
3. увеличена скорость сериализации/десериализации:
Binary serialization:
+-------------------+
| boost | YAS |
+------+---------+---------+---------+
| save | 142 ms | 24 ms | +500% |
+------+---------+---------+---------+
| load | 114 ms | 8 ms | +1300% |
+------------------------------------+
Text serialization:
+-------------------+
| boost | YAS |
+------+---------+---------+---------+
| save | 8090 ms | 277 ms | +28000% |
+------+---------+---------+---------+
| load | 8794 ms | 265 ms | +33000% |
+------------------------------------+
4. для текстовой сериализации были использованы сторонние конверторы integer->string/string->integer.
на данный момент, эти конверторы "прибиты гвоздями". это будет исправлено в течении нескольких дней, и после этого пользователи сами смогут указывать желаемые конверторы следующим образом:
Здравствуйте, niXman, Вы писали:
X>4. для текстовой сериализации были использованы сторонние конверторы integer->string/string->integer. X>на данный момент, эти конверторы "прибиты гвоздями". это будет исправлено в течении нескольких дней
done!
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
из серьезных изменений было сделано:
1. для текстовых архивов был переработан формат, что позволило наполовину уменьшить кол-во обращений к источнику/приемнику данных.
т.е. если в качестве источника/приемника данных используется файл, то кол-во операций чтения/записи(read()/write()) уменьшено вдвое.
2. YAS был добавлен в сравнителный тест сериализаторов/десериализаторов.
(первый коммит добавляющий YAS к этому тесту приняли, а второй, где я переработал отчеты — пока в ожидании. уикенды, мля)
зы
YAS все так же используется в игровых проектах, сериализуя/десериализуя пользовательский трафик, и трафик меж нод игровых серверов, так же для самопальной logfs, которую я закодил для хранения/сбора/обработки логов.
так же, возможно до конца года выкачу свою поделку, систему распределенного бэкапинга и синхронизации, с одной крайне необычной плюшкой. вам понравится
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
1) большие (а в наше время не особо большие) данные молча криво обрабатываются?
2) &string[0] — это реально стремно
3) надлежащие инклюды для std::uint32_t и других простых стандартных типов отсутствуют
4) С-style cast
ЗЫ не стоит прописывать в решениях полные пути типа D:\msys\home\niXman\
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
VTT>Студия 2015: 77 предупреждений VTT>mingw (g++ 5.1): 356 предупреждений VTT>clang 3.9: 345 предупреждений
приведите лог хоть какого-то из компиляторов. и команду сборки. спасибо.
VTT>1) большие (а в наше время не особо большие) данные молча криво обрабатываются?
не поняд...
VTT>2) &string[0] — это реально стремно
иначе придется константность снимать с c_str(). какие еще варианты?
VTT>3) надлежащие инклюды для std::uint32_t и других простых стандартных типов отсутствуют
исправлю.
VTT>4) С-style cast
да, некрасиво, согласен. исправлю.
VTT>ЗЫ не стоит прописывать в решениях полные пути типа D:\msys\home\niXman\
а где ты нашел это?
спасибо!
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
VTT>1) большие (а в наше время не особо большие) данные молча криво обрабатываются?
всегда использовать для этого uint64 — расточительно, как мне кажется...
возможно, перед size_type`ом записывать и необходимый размер удовлетворяющего size_type`а... т.е. sizeof(uint8)|sizeof(uint16)|sizeof(uint32)|sizeof(uint64)...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
VTT>>1) большие (а в наше время не особо большие) данные молча криво обрабатываются? X>всегда использовать для этого uint64 — расточительно, как мне кажется... X>возможно, перед size_type`ом записывать и необходимый размер удовлетворяющего size_type`а... т.е. sizeof(uint8)|sizeof(uint16)|sizeof(uint32)|sizeof(uint64)...
Для сериализации длины чего-либо часто используется простейшее кодирование значения называемое varint.
Не мой комментарий, но я помню, что тоже обратил внимание на эти моменты, когда смотрел в код.
VTT>>1) большие (а в наше время не особо большие) данные молча криво обрабатываются? X>не поняд...
Значения типа `size_t` (который может быть `uint64_t`) обрезаются до `uint32_t`
Если 8 байт для хранения нулевой дины кажется расточительным, надо смотреть на кодирование значения переменной длиной. Но есть шанс переместиться со 2-го места в середину списка в замерах скорости, к тем библиотекам, которые это уже делают.
Вообще тема длины строк и количества элементов в сериализуемых контейнерах в YAS не раскрыта. Как реагировать на строку длиной, например, 2^63?
VTT>>2) &string[0] — это реально стремно X>иначе придется константность снимать с c_str(). какие еще варианты?
Для string::data() в С++17 есть неконстантная перегрузка. Хорошо бы добавить защиту от пустых строк:
Сейчас, конечно, всё работает и так, потому что устройство строки во всех 3-х стандартных библиотеках более-менее одинаково. Но кто знает, как оно будет в будущем.
Здравствуйте, PM, Вы писали:
PM>Для сериализации длины чего-либо часто используется простейшее кодирование значения называемое varint.
я когда-то раньше уже думал об этом, был повод...
