Использование Protocol Buffers на платформе .Net (Часть 1)

[XuMiX]

Позволю себе продолжить ваши изыскания:
json.codeplex.com/releases/view/64935
The test of binary formatter:
1000 iterations in 122 ms
2000 iterations in 186 ms
3000 iterations in 286 ms
4000 iterations in 358 ms
5000 iterations in 450 ms

The test of protobuf-net:
1000 iterations in 137 ms
2000 iterations in 47 ms
3000 iterations in 72 ms
4000 iterations in 93 ms
5000 iterations in 118 ms

The test of json-net:
1000 iterations in 232 ms
2000 iterations in 200 ms
3000 iterations in 313 ms
4000 iterations in 406 ms
5000 iterations in 513 ms

The comparision of file size:
The size of tasks1.bin is 725 bytes
The size of tasks2.bin is 101 bytes
The size of tasks3.bin is 244 bytes

private static void TestJson(IList tasks, string fileName, int iterationCount)
{
var stopwatch = new Stopwatch();

using (var file = File.Create(fileName))
{
stopwatch.Restart();
for (var i = 0; i < iterationCount; i++)
{
var str = JsonConvert.SerializeObject(tasks);

var bytes = Encoding.UTF8.GetBytes(str);
file.Write(bytes, 0, bytes.Length);
file.Read(bytes, 0, bytes.Length);
file.Position = 0;
var restoredTasks = JsonConvert.DeserializeObject(Encoding.UTF8.GetString(bytes));
}

stopwatch.Stop();

Console.WriteLine("{0} iterations in {1} ms", iterationCount, stopwatch.ElapsedMilliseconds);
}
}

[osmirnov]

Выводы?

[XuMiX]

Выводы:
1. Можно юзать читаемый, переносимый и компактный Json.net вместо BinaryFormatter
2. Если хочется скорости — можно посмотреть в сторону других библиотек

[osmirnov]

Спасибо, согласен с читаемостью и переносимостью. Однако скорость по сравнению с protobuf-net ниже ~4х, а степень сжатия — в ~2х. Так что на выбор влияет не только скоростью, но и объём.

[bladebf]

хочется добавить, что в упомянутом Json.net в последних версиях (для .Net 4.0) реализовали нативную поддержку dynamic
<offtop>мы используем его совместно с Ext.Direct.Mvc для передачи данных на клиент и сохранения изменений на сервере, более чем удобно</offtop>

[XuMiX]

Ну, мы делаем то же самое, только в связке с Ext.Net

[mace]

Почему же так мало? Это даже не введение в protobuf, а статья типа «смотрите чего я нашел, смотрите — оно в быстрое!»

П.С. Недели две назад перевел проект на protobuf-net — пока полет нормальный, все работает как часы.

[osmirnov]

Мне казалось я в введение ответил на ваш вопрос.

[mace]

На самом деле просто не надо было постить весь код, который тестирует производительность. Его ведь можно было выложить на каком-нибуть pastebin или аналогичном сервисе. Сейчас в статье очень мало смысла.

[osmirnov]

Спасибо за замечание. Постараюсь учесть на будущее. Что касается смысла, стояла цель познакомить читателя с основами. Я понимаю, что вам как зубру разработки кажется написанное очевидным, особенно, после того как внедрили protobuf-net у себя; но, повторюсь, топик рассчитан на новичков.

[crjd]

Что планируется в продолжении?

[osmirnov]

Продолжение разговора про переносимость и использование protobuf-net в контексте wcf.

[acerv]

чегоб не написать одну статью, потом ее разбить на две и обе запостить сразу? что мешает? жадность?

[osmirnov]

Жадность чего? Вторую часть как раз заканчиваю, завтра с утра со свежей головой еще раз прочитаю и выложу.

[crjd]

Сравнения protobuf библиотек для .net не планируется?

[osmirnov]

К сожалению, нет, а есть смысл? Protobuf-net самый активный порт.

[boolean]

Недавно прикрутил эту библиотеку как сериалайзер между wcf-сервисом и silverlight-приложением. Скорость обработки сообщений выросло где-то в два раза при значительном сокращении размера сообщения.
Пока работает отлично, так что рекомендую :-)

[qehgt]

У protobuf было два недостатка в тот момент когда мы рассматривали его как кандидат для использования в нашем проекте:
— не хранится «размер сообщения», то есть если использовать этот сериализатор для пересылки сообщений, надо либо дважды «заворачивать» данные, либо делать протокол передачи,
— отсутствует стандартный RPC (строго говоря, нам нужен был именно RPC+сериализация) от «отца-основателя». В результате этих RPC (которые используют внутри себя protobuf) существует несколько, друг с другом не совместимых.

«Независимая от языка сериализация» — она зачастую когда нужна? Когда делается клиент-серверная архитектура, в которой клиент (или клиенты) написаны на другом языке (языках), чем серверная часть. Описали протокол сериализации — сделайте и следующий шаг: опишите формат сообщений/ответов. Ценность библиотеки выросла бы многократно.

[boolean]

Ну protobuf — это же просто сериализатор. А где, как и для чего передавать данные уже решаете Вы, так же, как и куда слать размер данных.
А эта реализация для .Net очень просто прикручивается к WCF с помощью атрибутов.

[mezastel]

У меня вопрос! А имеет ли смысл использовать protobuf для передачи структур между С++ и .Net проектами? Просто у меня есть проект, который сейчас mixed-mode и использует P/Invoke методы с большим кол-вом параметров.

[osmirnov]

Думаю смысл есть, Дмитрий. Однако существуют некоторые ограничения, я упомяну о них в следующей части.

[mezastel]

А где можно найти примерчик такого взаимодействия? Понимаю что можно искать инфу по частям, но мне reference project Был бы полезней

[osmirnov]

На стеке полно ссылок с вопросами на эту тему, но найти готовый пример для вас, увы, найти не получилось (сам на C++ не писал уже лет 5, поэтому писать его самостоятельно не рискну). Если найдёте время для такого примера, буду рад, если поделитесь результатами здесь или у себя в блоге.

[osmirnov]

Сегодня совершенно случайно нашёл пример такого взаимодействия в блоге Alexey Korotaev.

[googol]

Protobuf как раз и создавался для кросс-платформенной, кросс-языковой передачи сообщений. Так что теоретически Protobuf/Apache Thrift это то что нужно.

[adontz]

У меня была проблема огромного трафика WCF сервиса. Я тоже смотрел в сторону protocol buffers, но в итоге передумал и до сих пор гоняю XML между клиентом и сервером полученный DataContractSerializer. Вместо огромного по объёму переписывания кода (все DTO разметить, ого-го), я просто перешёл на HTTP и поставил перед сервисом gzip'ующий nginx. Трафик уменьшился в 8.5 раз, а для расжатия на клиентской стороне вообще ничего делать не пришлось. Ну и работы часа на два от силы, на protobuf-net явно больше надо. Тот же финт с сжатием может делать и Apache.

[osmirnov]

Идея супер! Сам хотел поковырять IIS для этого, но пока руки не дошли. Об nginx как-то особо не думал для этой цели.

Относительно переписывания DTO, там не так много работы. Фактически, в protobuf-net для этого такая поддержка, что по контракту данных и не скажешь, что используется protobuf-net. Об этом в следующей части)

[boolean]

А у Вас WCF сервис хостится на IIS? Если да, то там есть поддержка gzip'а из коробки и не нужно ставить перед ним ngix.

[adontz]

Нет, не в IIS и он не может хостится в IIS по техническим причинам.

[Alerman]

В статье «Когда речь заходит о сериализации в .Net, все обычно вспоминают о существовании бинарного форматера и xml сериализатора. Следующее, что отмечают разработчики, то, что первый быстрый и имеет высокую степень сжатия, но работает только в пределах .Net платформы; а второй представляет данные в человеко-читабельном формате»
Я считаю правильнее было бы: "… первый имеет невысокую степень избыточности..."

[osmirnov]

Спасибо, вы, конечно, правы, но думаю «сжатие» больше понятно большинству читателей, хотя и не совсем точно.

[ncix]

реализациии protobuf существует для более чем 20 языков

Почему-то для Delphi как всегда нет. Тенденция, однако