Высокопроизводительная сериализация: Java по сравнению с Google Protocol Buffers по сравнению с …?

Простая логика говорит нам, что компиляция огромной программы размера MS Office даже из байт-кодов займет слишком много времени. У вас будет огромное время пуска, и это напугает любого из вашего продукта. Конечно, вы можете прекомпилировать во время установки, но это также имеет последствия.

Еще одна причина заключается в том, что не все части приложения будут использоваться. JIT будет компилировать только те части, которые заботятся о пользователях, оставляя потенциально 80% кода нетронутыми, экономя время и память.

И, наконец, компиляция JIT может применять оптимизации, которые обычные компиляторы не могут. Подобно встраиванию виртуальных методов или частей методов с деревьями трассировки . Который, теоретически, может сделать их быстрее.

52
задан cletus 15 March 2009 в 13:00
поделиться

5 ответов

Я не сравнил Буферы Протокола с собственной сериализацией Java с точки зрения скорости, но для собственной сериализации Java совместимости серьезное нет - нет. Это также не собирается быть столь же эффективным с точки зрения пространства как Буферы Протокола в большинстве случаев. Конечно, это несколько более гибко с точки зрения того, что это может сохранить, и с точки зрения ссылок и т.д. Буферы Протокола очень хороши в том, что предназначается для, и когда это соответствует Вашей потребности, это является большим - но существуют очевидные ограничения из-за совместимости (и другие вещи).

я недавно отправил Протокол Буферы, сравнивающие платформы в Java и.NET. Версия Java находится в основной проект Google (в каталог сравнительных тестов), версия.NET находится в мой проект порта C#. Если Вы хотите сравнить скорость петабайта со скоростью сериализации Java, Вы могли бы записать подобные классы и сравнить их. Если бы Вы интересуетесь interop, хотя, я действительно не дал бы собственную сериализацию Java (или собственный компонент.NET двоичная сериализация) долгое размышление.

существуют другие опции для совместимой сериализации помимо Буферов Протокола, хотя - Экономия , JSON и YAML приходит на ум, и существуют, несомненно, другие.

РЕДАКТИРОВАНИЕ: Хорошо, с interop, не являющимся настолько важным, стоит попытаться перечислить различные качества, которые Вы хотите из платформы сериализации. Одной вещью, о которой необходимо думать, является управление версиями - это - другая вещь, которую петабайт разработан для обработки хорошо, и назад и вперед (таким образом, новое программное обеспечение может считать старые данные и наоборот) - когда Вы придерживаетесь предложенных правил, конечно:)

попытавшийся быть осторожным относительно производительности Java по сравнению с собственной сериализацией, я действительно не был бы удивлен найти, что петабайт был быстрее так или иначе. Если у Вас есть шанс, используйте сервер vm - мои недавние сравнительные тесты показали серверу VM, чтобы быть более чем вдвое более быстры при сериализации и десериализации демонстрационных данных. Я думаю, что код петабайта удовлетворяет JIT VM's сервера очень приятно:)

Так же, как демонстрационная производительность фигурирует, сериализируя и десериализовывая два сообщения (228 байтов, 84 750 байтов), я получил эти результаты на своем ноутбуке с помощью сервера VM:

Benchmarking benchmarks.GoogleSize$SizeMessage1 with file google_message1.dat 
Serialize to byte string: 2581851 iterations in 30.16s; 18.613789MB/s 
Serialize to byte array: 2583547 iterations in 29.842s; 18.824497MB/s 
Serialize to memory stream: 2210320 iterations in 30.125s; 15.953759MB/s 
Deserialize from byte string: 3356517 iterations in 30.088s; 24.256632MB/s 
Deserialize from byte array: 3356517 iterations in 29.958s; 24.361889MB/s 
Deserialize from memory stream: 2618821 iterations in 29.821s; 19.094952MB/s 

Benchmarking benchmarks.GoogleSpeed$SpeedMessage1 with file google_message1.dat 
Serialize to byte string: 17068518 iterations in 29.978s; 123.802124MB/s 
Serialize to byte array: 17520066 iterations in 30.043s; 126.802376MB/s 
Serialize to memory stream: 7736665 iterations in 30.076s; 55.93307MB/s 
Deserialize from byte string: 16123669 iterations in 30.073s; 116.57947MB/s 
Deserialize from byte array: 16082453 iterations in 30.109s; 116.14243MB/s
Deserialize from memory stream: 7496968 iterations in 30.03s; 54.283176MB/s 

Benchmarking benchmarks.GoogleSize$SizeMessage2 with file google_message2.dat 
Serialize to byte string: 6266 iterations in 30.034s; 16.826494MB/s 
Serialize to byte array: 6246 iterations in 30.027s; 16.776697MB/s 
Serialize to memory stream: 6042 iterations in 29.916s; 16.288969MB/s 
Deserialize from byte string: 4675 iterations in 29.819s; 12.644595MB/s 
Deserialize from byte array: 4694 iterations in 30.093s; 12.580387MB/s 
Deserialize from memory stream: 4544 iterations in 29.579s; 12.389998MB/s 

Benchmarking benchmarks.GoogleSpeed$SpeedMessage2 with file google_message2.dat 
Serialize to byte string: 39562 iterations in 30.055s; 106.16416MB/s 
Serialize to byte array: 39715 iterations in 30.178s; 106.14035MB/s 
Serialize to memory stream: 34161 iterations in 30.032s; 91.74085MB/s 
Deserialize from byte string: 36934 iterations in 29.794s; 99.98019MB/s 
Deserialize from byte array: 37191 iterations in 29.915s; 100.26867MB/s 
Deserialize from memory stream: 36237 iterations in 29.846s; 97.92251MB/s 

"скорость" по сравнению с "размером" состоит в том, оптимизирован ли сгенерированный код для скорости или размера кода. (Сериализированные данные являются тем же в обоих случаях. Версия "размера" обеспечивается для случая, где Вы имеете много определенных сообщений и не хотите брать большую память для кода.)

, Как Вы видите для меньшего сообщения, это может быть очень быстро - более чем 500 маленьких сериализированных сообщений или десериализовало на миллисекунду . Даже с сообщением 87K это берет меньше, чем миллисекунда на сообщение.

60
ответ дан Gab是好人 7 November 2019 в 19:22
поделиться

Еще одна точка данных: этот проект:

http://code.google.com/p/thrift-protobuf-compare/

дает некоторое представление об ожидаемой производительности для маленьких объектов, включая сериализацию Java на ПБ.

Результаты варьируются много в зависимости от Вашей платформы, но существуют некоторые общие тенденции.

15
ответ дан StaxMan 7 November 2019 в 09:22
поделиться

То, что делает Вас, подразумевает под высокой производительностью? Если Вы хотите сериализацию миллисекунды, я предлагаю, чтобы Вы использовали подход сериализации, который является самым простым. Если Вы захотите sub миллисекунду, то Вам, вероятно, будет нужен двоичный формат. Если Вы захотите много ниже 10 микросекунд, то Вам, вероятно, будет нужна пользовательская сериализация.

я не видел много сравнительных тестов для сериализации/десериализации, но немногие поддерживают меньше что 200 микросекунд для сериализации/десериализации.

Независимые от платформы форматы прибывают в стоимость (в усилии с Вашей стороны и задержке), Вам, вероятно, придется решить, хотите ли Вы производительность или независимость от платформы. Однако нет никакой причины, у Вас не может быть обоих как параметра конфигурации, между которым Вы переключаетесь как требуется.

5
ответ дан Peter Lawrey 7 November 2019 в 19:22
поделиться

Если Вы сбиваете с толку между петабайтом & собственная сериализация Java на скорости и эффективности, просто пойдите для петабайта.

  • петабайт был разработан для достижения таких факторов. См. http://code.google.com/apis/protocolbuffers/docs/overview.html
  • , данные петабайта являются очень маленькими, в то время как сериализация Java имеет тенденцию копировать целый объект, включая его подпись. Почему я всегда получаю свое имя класса, имя поля... сериализированное, даже при том, что я очень хорошо знаю его в получателе?
  • Думают о через разработку языка. Становится трудным, если одна сторона использует Java, одна сторона использует C++...

Некоторые разработчики предлагают Экономию, но я использовал бы Google PB, потому что "Я верю в Google":-).. Так или иначе это стоит для взгляда: http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers

6
ответ дан instcode 7 November 2019 в 19:22
поделиться

Вот от стенного предложения дня:-) (Вы просто настроили что-то в моей голове, которую я теперь хочу попробовать)...

, Если можно пойти для целого решения для кэширования через это, оно могло бы работать: Darkstar Проекта. Это разработано как очень высокопроизводительный игровой сервер, конкретно так, чтобы чтения были быстры (настолько хороший для кэша). Это имеет Java и API C, таким образом, я верю (мысль, это было долгое время, так как я посмотрел на него, и я не думал об этом тогда), что Вы могли сохранить объекты с Java и считать их назад в C и наоборот.

, Если ничто иное это даст Вам что-то для чтения на сегодня:-)

1
ответ дан TofuBeer 7 November 2019 в 19:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: