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

Позволю себе продолжить ваши изыскания:
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);
}
}

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

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

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

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

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

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

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

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

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

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

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