Сравнение производительности Экономии, Буферов Протокола, JSON, EJB, другого?

Можно интересоваться этим вопросом: "Самые большие различия Экономии по сравнению с Буферами Протокола?"

Я нахожусь в процессе записи некоторого кода в проект с открытым исходным кодом, названный thrift-protobuf-compare, выдерживающим сравнение между protobuf и экономией. На данный момент это покрывает немного аспектов сериализации, но я намереваюсь покрыть больше. Результаты (для Экономия и Protobuf) обсуждены в моем блоге, я добавлю больше, когда я доберусь до него. Можно посмотреть на код для сравнения API, языка описания и сгенерированного кода. Я буду рад иметь вклады для достижения более округленного сравнения.

Я сделал проведение испытаний петабайта с количеством других форматов данных (xml, json, сериализация объекта по умолчанию, гессиан, одна собственная) и библиотеки (jaxb, быстрый инфонабор, рукописный) для задачи привязки данных (и чтение и запись), но формат (форматы) экономии не был включен. Производительность для форматов с несколькими преобразователями (как xml) имела очень высокое различие от очень медленного до pretty-darn-fast. Корреляция между требованиями авторов и воспринятой производительности была довольно слаба. Особенно так для пакетов, которые предъявили самые дикие претензии.

Если это имеет значение, я нашел, что производительность петабайта была битом по раздутому (обычно не его авторами, но другими, которые только знают, кто записал это). С настройками по умолчанию это не разбило самую быструю текстовую xml альтернативу. С оптимизированным режимом (почему это не значение по умолчанию?), это был бит, быстрее, сопоставимый с самым быстрым пакетом JSON. Гессиан был довольно быстрым, текстовым json также. Двоичный формат Properietary (никакое имя здесь, это была внутренняя компания), было самым медленным. Сериализация объекта Java была быстра для больших сообщений, меньше для маленьких объектов (т.е. высоко зафиксировал noverhead на операцию). С петабайтом размер сообщения был компактен, но, учитывая все компромиссы необходимо сделать (данные не являются самодокументированными: при потере схемы Вы теряете данные; существуют индексы, конечно, и оценивают типы, но от того, что Вы имеете, перепроектируют назад к именам полей, если бы Вы хотите), я лично только выбрал бы его для определенных вариантов использования - чувствительный к размеру, тесно двойная система, где интерфейс/формат никогда (или очень очень редко) не изменяется.

Мое мнение в этом то, что (a) реализация часто имеет значение больше, чем спецификация (формата данных), (b) от начала до конца различия между лучшим среди аналогов (для различных форматов) являются обычно не достаточно большими для диктовки выбора. Таким образом, можно быть более обеспеченным выбором format+API/lib/framework, Вам нравится использовать большинство (или имеет лучшую поддержку инструмента), найдите лучшую реализацию и посмотрите, работает ли это достаточно быстро. Если (и только если!) не, рассмотрите затем лучшую альтернативу.

PS, Не уверенный, каков EJB3 здесь был бы. Возможно, просто сериализации Java?

Одна из вещей около вершины мой "к - действительно" перечисляет для PBS, должен портировать внутренний протокол Google Буферный сравнительный тест производительности - это - главным образом случай взятия конфиденциальных форматов сообщения и превращения их в совершенно мягкие и затем выполнение того же для данных.

, Когда это было сделано, я предположу, что Вы могли создать те же сообщения в Экономии и затем сравнить производительность.

, Другими словами, у меня еще нет данных для Вас - но надо надеяться за следующие несколько недель...

Если необработанная сетевая производительность является целью, то ничто не бьет IIOP (см. RMI/IIOP). Самое маленькое место - только двоичные данные, никакая разметка вообще. Сериализация/десериализация очень быстра также.

, Так как это - IIOP (который является CORBA), почти все языки имеют привязку.

, Но я предполагаю, что производительность не [только 113] требование, правильно?