но я не об этом.скажите, нужна ли вообще бинарная сериализация? ведь с ней куча проблем...
в каких к примеру случаях без не никак?
почему не использовать только текстовую сериализацию?
спасибо.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > нужна ли вообще бинарная сериализация? |
| Автор: boostcoder 24.7.2011, 22:39 |
| как возможно некоторые помнят, недавно я обсуждал реализацию библиотеки сериализации, т.к. от бустовской пришлось отказаться в виду ее непригодности по ряду причин но я не об этом. скажите, нужна ли вообще бинарная сериализация? ведь с ней куча проблем... в каких к примеру случаях без не никак? почему не использовать только текстовую сериализацию? спасибо. |
| Автор: volatile 24.7.2011, 23:22 | ||
Имхо, любые данные можно преобразовать в текстовый вид, так что не думаю что может быть какой-то случай, что без бинарной - никак. Просто бинарную (теоретически) можно сделать более эффективной. (меньшее кол-во преобразовний, меньше размер выходного файла и т.д.) Так-что если произодительность сериализации не имеет решающего значения, то текстовой вполне можно обойтись. |
| Автор: borisbn 24.7.2011, 23:40 | ||
Одна из которых, что далеко не всегда бинарные данные меньше текстовых. Например, число double, равное 3,14 в тесте занимает 4 байта, а в бинаре - 8, все целые числа меньше 1000 занимают меньше места, чем int (а таких немало - всякие индексы и т.п.) Плюс к тому при больших объёмах текстовая информация гораздо лучше жмётся. У меня так в одном большом проекте данные перегоняются по сети - с одной стороны сериализуются в XML и сжимаются zip-ом, а на другой стороне - разжимаются и десериализуются. Объём получился раза в 2 меньше. Время, правда, тратится на сжимание/разжимание, но, т.к. компы там быстрые, а сеть медленная (2 МБита), то овчинка выделки стоит. А про то, что для отладки текстовый формат удобнее, думаю и говорить не стоит. В общем в каждом конкретном случае нужно пробовать (ну или прикидывать, если получится) оба варианта и выбирать оптимальный. |
| Автор: boostcoder 25.7.2011, 00:37 |
| суть вопроса заключалась и в том, что возможно есть ситуации когда бинарная сериализация не заменима, но я об этом не знаю. у бинарной сериализации один существенный плюс - она очень быстрая. текстовая сериализация почти в 6 раз медленней. нужно искать способ избавится от стандартных потоков... |
| Автор: volatile 25.7.2011, 00:48 | ||||
|
| Автор: boostcoder 25.7.2011, 00:52 |
volatile, вашу позицию я понял  |
| Автор: afiskon 25.7.2011, 06:28 |
| Ну да, скорость, объем данных. На принтерах или бюджетных роутерах это может быть существенно. Если объект планируется шифровать, бинарные данные также предпочтительнее (если вы - параноик, террорист или работаете в гос. структуре). Если скорость не очень важна (а железо сейчас дешевое), преобразовать текстовые данные в бинарные можно с помощью алгоритма сжатия (LZW вполне сойдет). Тут плюс в том, что бинарные данные будет легко преобразовать в текстовые, а текстовые данные хорошо парсятся скриптами или библиотеками (XML). По-моему, это хороший компромисс. |
| Автор: boostcoder 25.7.2011, 06:34 | ||
любопытно. спасибо  |
| Автор: phprus 25.7.2011, 07:54 | ||||||
Есть:
К примеру в моих задачах передавать снимаемые с датчиков данные (650+Мбит/с) применяется ручная бинарная сериализация (правда она имеет достаточно простую структуру, набор блоков разной длины без хранения информации о типе данных в блоке). Текстовая сериализация здесь не подошла бы по скорости. Да и алгоритмов сжатия, способных переварить в среднем 650+Мбит/с на имеющемся у нас оборудовании я не встречал.
Только до определенного предела, потом стоимость сопровождения оборудования начинает быстро расти. |
| Автор: Earnest 25.7.2011, 08:09 |
| В общем да, дело не в незаменимости, а в скорости и объеме. Чтение текстовых данных - это всегда в том или ином виде интерпретация. Т.е. писать загрузку сложнее. При этом скорость чтения вовсе не использованием потоков определяется, а именно интерпретацией. Бинарные - просто читаем as is. И проще контролировать целостность. Что касается объема... Например, графические данные (векторные). Тот же DXF, скажем, может занимать несколько мегабайт, а в бинарном виде - килобайты. Или растр. Посмотрела бы я на эту радость в текстовом виде... Что касается удобства отладки, то не очень представляю, что там за проблемы: что в коде ковыряться, что в огромном текстовом файле - радость небольшая. Но и то и другое - рутина. Преимущество текстового формата - его проще сделать расширяемым и независимым от версии данных. |
| Автор: boostcoder 25.7.2011, 09:32 | ||
phprus, да. скорость - это единственный положительный момент.
это ооочень зависит... |
| Автор: azesmcar 25.7.2011, 09:40 | ||
Осуществить твое желание поможет base64 |
| Автор: Earnest 25.7.2011, 09:47 | ||||
Разве я говорила, что хочу? А представить очень даже могу... 
В смысле? Конечно, от формата зависит. Но как правило плотность информации на единицу объема в бинарных данных значительно выше... |
| Автор: azesmcar 25.7.2011, 09:51 | ||
| Earnest Я имел ввиду, что
не так уж страшно |
| Автор: mes 25.7.2011, 11:15 | ||
не совсем так.. это преимущество формата с тегами над "голым" отражением и напрямую не зависит от того текстовой формат или бинарный.. Добавлено через 36 секунд azesmcar, сорри не понял с какой позиции была приведена base64 ? |
| Автор: azesmcar 25.7.2011, 11:23 | ||
Base64 используется для конвертации бинарных данных в текстовом виде. |
| Автор: mes 25.7.2011, 11:42 | ||
да, но используется для того чтоб можно было передавать бинарные данные через текстовые каналы, однако когда говорят текстовая сериализация, подразумевается, что выходные данные будут "дружественные человеку".. base64 такого не дает.. |
| Автор: azesmcar 25.7.2011, 12:08 | ||
Далеко не все можно привести в дружественный человеку вид. Как вы предполагаете привести в дружественный вид mp3? На ноты разложить? |
| Автор: Earnest 25.7.2011, 12:17 | ||||
Это правда, но текстовый формат сложно представить без тегов или чего-то вроде, а бинарные обычно жесткие. Ну или с произвольным порядком данных, предваряемых типом (тэгом?). Добавлено через 10 минут и 45 секунд
В "текстовом" виде бинарные данные пишут как, например, binary data в реестре или профиле (ini). Т.е. в виде "0FAA566BC89098BCD ...", шестнадцатеричными буквами. Под "дружественным" же понимается возможность читать глазами без отладчика и бинарных вьюеров. Та еще "дружба", в общем. |
| Автор: mes 25.7.2011, 12:40 | ||
речь не о том, что можно привести, а что нет, а о том, что base64 не является аналогом текстовой сериализации (в ее принятом по умолчанию значению) и не имеет тех качеств, которые являются преимуществами текстовой сериализации, а является все тем же бинарным отражением данных, только приспособленных для передачи по "текстовому каналу".. Поэтому не смотря на текстовой вид base64 все ж бинарная Добавлено через 46 секунд о чем впрочем говорит ее название |
| Автор: azesmcar 25.7.2011, 12:45 | ||
Так можно конечно, но тогда получиться 100% оверхэд в размере. |
