Как получается, что сериализация json намного быстрее, чем сериализация yaml в Python?

У меня есть код, который в значительной степени зависит от yaml для многоязыковой сериализации, и, работая над ускорением некоторых вещей, я заметил, что yaml был безумно медленным по сравнению с другими методами сериализации (например, pickle, json).

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

>>> import yaml, cjson; d={'foo': {'bar': 1}} >>> yaml.dump(d, Dumper=yaml.SafeDumper) 'foo: {bar: 1}\n' >>> cjson.encode(d) '{"foo": {"bar": 1}}' >>> import yaml, cjson; >>> timeit("yaml.dump(d, Dumper=yaml.SafeDumper)", setup="import yaml; d={'foo': {'bar': 1}}", number=10000) 44.506911039352417 >>> timeit("yaml.dump(d, Dumper=yaml.CSafeDumper)", setup="import yaml; d={'foo': {'bar': 1}}", number=10000) 16.852826118469238 >>> timeit("cjson.encode(d)", setup="import cjson; d={'foo': {'bar': 1}}", number=10000) 0.073784112930297852 

Pyyaml ​​CSafeDumper и cjson написаны на C, так что это не так, как проблема с версией C vs Python. Я даже добавил к нему некоторые случайные данные, чтобы узнать, делает ли cjson какое-либо кэширование, но он все еще быстрее, чем PyYaml. Я понимаю, что yaml является надмножеством json, но как может быть медленный последователь с ямлом на 2 порядка медленнее с таким простым вводом?

4 Solutions collect form web for “Как получается, что сериализация json намного быстрее, чем сериализация yaml в Python?”

В общем, не сложность вывода определяет скорость разбора, а сложность принятого ввода. Грамматика JSON очень кратка . Анализаторы YAML сравнительно сложны , что приводит к увеличению накладных расходов.

Главной целью дизайна JSON является простота и универсальность. Таким образом, JSON тривиально генерировать и анализировать за счет снижения удобочитаемости человека. Он также использует самую низкую общую информационную модель знаменателя, гарантируя, что любые данные JSON могут быть легко обработаны каждой современной средой программирования.

Напротив, главные цели дизайна YAML – это удобство чтения и поддержка сериализации произвольных встроенных структур данных. Таким образом, YAML позволяет получать чрезвычайно читаемые файлы, но сложнее генерировать и анализировать. Кроме того, YAML выходит за пределы самых низких типов данных общего знаменателя, требуя более сложной обработки при пересечении различных сред программирования.

Я не являюсь разработчиком синтаксического анализатора YAML, поэтому я не могу говорить конкретно с порядком величины без каких-либо профилирующих данных и большого массива примеров. В любом случае, обязательно испытайте большой объем входных данных, прежде чем почувствовать уверенность в контрольных номерах.

Обновить Упс, неправильно спросите вопрос. 🙁 Сериализация все еще может быть невероятно быстрой, несмотря на большую грамматику ввода, однако, просматривая источник, похоже, что сериализация PyYAML на уровне Python создает граф представления, тогда как simplejson кодирует встроенные типы данных Python непосредственно в текстовые фрагменты.

В приложениях, над которыми я работал, вывод типа между строками в числа (float / int) заключается в том, что наибольшие издержки для разбора yaml связаны с тем, что строки могут быть записаны без кавычек. Поскольку все строки в json находятся в кавычках, при анализе строк нет возврата. Отличным примером, где это будет замедляться, является значение 0000000000000000000. Вы не можете сказать, что это значение является строкой, пока вы не прочитали ее до конца.

Другие ответы верны, но это конкретная деталь, которую я обнаружил на практике.

Говоря об эффективности, я использовал YAML какое-то время и почувствовал притягательность простотой, что некоторые названия и ценности присваиваются на этом языке. Тем не менее, в этом процессе я так часто спотыкался об одной из утонченностей YAML, тонких вариациях в грамматике, которые позволяют писать специальные случаи в более сжатом стиле и т. Д. В конце концов, хотя грамматика YAML почти наверняка формально последовательна, она оставила меня с определенным чувством «неопределенности». Затем я ограничился тем, чтобы не трогать существующий, работающий код YAML и писать все новое в более кольцевом, отказоустойчивом синтаксисе, что заставило меня отказаться от всего YAML. Результатом является то, что YAML пытается выглядеть как стандарт W3C и создает небольшую библиотеку трудночитаемой литературы, касающуюся ее концепций и правил.

По-моему, это гораздо более интеллектуальные издержки, чем нужно. Посмотрите на SGML / XML: разработанный IBM в ревущих 60-х годах, стандартизованный ISO, известный (в заглушенном и измененном виде), как HTML, для бесчисленных миллионов людей, документированный и документированный и документированный снова во всем мире. Приходит маленький JSON и убивает этого дракона. Как JSON стал настолько широко использоваться за столь короткий промежуток времени, только с одним скудным сайтом (и подсветкой javascript для его поддержки)? Это простота, простое отсутствие сомнений в грамматике, простота обучения и использования.

XML и YAML трудны для людей, и они сложны для компьютеров. JSON довольно дружелюбен и прост для людей и компьютеров.

Беглый взгляд на python-yaml предполагает, что его дизайн намного сложнее, чем cjson's:

 >>> dir(cjson) ['DecodeError', 'EncodeError', 'Error', '__doc__', '__file__', '__name__', '__package__', '__version__', 'decode', 'encode'] >>> dir(yaml) ['AliasEvent', 'AliasToken', 'AnchorToken', 'BaseDumper', 'BaseLoader', 'BlockEndToken', 'BlockEntryToken', 'BlockMappingStartToken', 'BlockSequenceStartToken', 'CBaseDumper', 'CBaseLoader', 'CDumper', 'CLoader', 'CSafeDumper', 'CSafeLoader', 'CollectionEndEvent', 'CollectionNode', 'CollectionStartEvent', 'DirectiveToken', 'DocumentEndEvent', 'DocumentEndToken', 'DocumentStartEvent', 'DocumentStartToken', 'Dumper', 'Event', 'FlowEntryToken', 'FlowMappingEndToken', 'FlowMappingStartToken', 'FlowSequenceEndToken', 'FlowSequenceStartToken', 'KeyToken', 'Loader', 'MappingEndEvent', 'MappingNode', 'MappingStartEvent', 'Mark', 'MarkedYAMLError', 'Node', 'NodeEvent', 'SafeDumper', 'SafeLoader', 'ScalarEvent', 'ScalarNode', 'ScalarToken', 'SequenceEndEvent', 'SequenceNode', 'SequenceStartEvent', 'StreamEndEvent', 'StreamEndToken', 'StreamStartEvent', 'StreamStartToken', 'TagToken', 'Token', 'ValueToken', 'YAMLError', 'YAMLObject', 'YAMLObjectMetaclass', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__', '__version__', '__with_libyaml__', 'add_constructor', 'add_implicit_resolver', 'add_multi_constructor', 'add_multi_representer', 'add_path_resolver', 'add_representer', 'compose', 'compose_all', 'composer', 'constructor', 'cyaml', 'dump', 'dump_all', 'dumper', 'emit', 'emitter', 'error', 'events', 'load', 'load_all', 'loader', 'nodes', 'parse', 'parser', 'reader', 'representer', 'resolver', 'safe_dump', 'safe_dump_all', 'safe_load', 'safe_load_all', 'scan', 'scanner', 'serialize', 'serialize_all', 'serializer', 'tokens'] 

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

  • Отключить преобразование значения PyYAML
  • Получение ученого представления данных из неконтролируемого обучения в pylearn2
  • python yaml.dump плохой отступ
  • Обслуживание статического html в Google app engine Python
  • Как я могу контролировать, какую скалярную форму PyYAML использует для моих данных?
  • Есть ли выигрыш в производительности от определения маршрутов в app.yaml по сравнению с одним большим отображением в WSGIApplication в AppEngine?
  • В Python, как вы можете загружать сопоставления YAML как OrderedDicts?
  • Как предотвратить YAML для сбрасывания длинной строки без новой строки
  • словарь yaml multi вложен и словарь python
  • Разберите YAML и предположим, что определенный путь всегда является строкой
  • как писать файл yaml
  • Python - лучший язык программирования в мире.