Существуют ли различия в производительности между двоичной и XML-сериализацией?

Неа.

Это сильно зависит от того, какие данные находятся внутри самого XML-документа. Если у вас много структурированных данных, накладные расходы для XML будут большими. Например, если ваши данные выглядят так:

<person>
  <name>Dave</dave>
  <ssn>000-00-0000</ssn>
  <email1>xxxxxx/email1>
</person>
...

У вас будет намного больше накладных расходов, чем если бы у вас был XML-документ, который выглядит так:

<book name="bible">
 In the beginning God created the heavens and the earth. 
 Now the earth was formless and empty ... 
 And if any man shall take away from the words of the book of this prophecy, God shall take away his part out of the book of life, and out of the holy city, and from the things which are written in this book. He which testifieth these things saith, Surely I come quickly. Amen. Even so, come, Lord Jesus.
</book>

Так что это не совсем корректный вопрос. Это сильно зависит от данных, которые ВЫ собираетесь отправить, и от того, как/если вы их сжимаете.

Самая большая разница между сериализацией BinaryFormatter и xml заключается в переносимости; BinaryFormatter трудно гарантировать между версиями, поэтому он действительно подходит только для кратковременного хранения или передачи.

Тем не менее, вы можете получить лучшее из обоих, и сделать его меньше, и сделать это быстрее, используя специальную двоичную сериализацию - и вам даже не нужно делать это самостоятельно. ;-п

protobuf-net — это реализация .NET спецификации двоичной сериализации буферов протокола Google; он меньше, чем XmlSerializer или BinaryFormatter, полностью переносим (не только между версиями — вы можете загружать поток pb, например, в java и т. д.), расширяем и быстр. Он также довольно всесторонне протестирован с большим количеством пользователей.

Полная разбивка размера и скорости, охватывающая XmlSerializer, BinaryFormatter, DataContractSerializer и protobuf-net, приведена . здесь.

Инстинктивно вы хотели бы сказать, что двоичный код более эффективен, но на самом деле это зависит от сериализуемых данных.

Ознакомьтесь с этой статьей: http://www.nablasoft.com/alkampfer/index.php/2008/10/31/binary-versus-xml-serialization-size/

Просто указание на производительность — не единственная метрика, на которую вы можете обратить внимание.

• Легкость конструкции. У вас есть несколько дней/недель, чтобы создать процедуру сериализатора/десериализатора и тщательно ее протестировать, или это время лучше потратить на функции?
• Простота использования данных. Может ли клиент использовать предварительно созданный синтаксический анализатор с открытым исходным кодом или ему нужно самостоятельно реализовать кучу (потенциально ошибочного) кода?
• Простота отладки. Поможет ли возможность просмотра данных в пути отладке? Тогда двоичный формат будет скрывать любые проблемы.
• Какова стоимость обслуживания для каждого метода?

Лично я бы использовал опубликованный стандарт XML и библиотеки синтаксического анализа с открытым исходным кодом до тех пор, пока реальное тестирование не подтвердит узкое место в производительности.