Разбор JSON быстрее, чем разбор XML


Я создаю сложную библиотеку JavaScript для работы с серверной частью моей компании.

серверная платформа кодирует свои данные в простой формат XML. Там нет причудливого пространства имен или чего-то подобного.

В идеале я хотел бы проанализировать все данные в браузере как JSON. Однако, если я это сделаю, Мне нужно переписать часть кода на стороне сервера, чтобы также выплюнуть JSON. Это боль, потому что у нас есть публичные API, которые я не могу легко изменение.

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

Я понимаю, что большинство современных веб-разработчиков, вероятно, выберут JSON, и я могу понять, почему. Тем не менее, я действительно просто заинтересован в производительности. Если есть доказанный массивный разница тогда я готов потратить дополнительные усилия на создание JSON-сервера для клиента.

11 54

11 ответов:

JSON должен быть быстрее, так как это JS обозначение объекта, что означает, что он может быть распознан изначально JavaScript. В PHP на GET стороне вещей, я часто буду делать что-то вроде этого:

<script type="text/javascript">
    var data = <?php json_encode($data)?>;
</script>

для получения дополнительной информации об этом см. здесь:

почему все выбирают JSON вместо XML для jQuery?

также...какие " дополнительные усилия "вам действительно нужно приложить для" генерации " JSON? Конечно, вы не можете сказать, что вы будете ручное построение строки JSON? Почти каждый современный серверный язык имеет библиотеки, которые преобразуют собственные переменные в строки JSON. Например, ядро PHP json_encode функция преобразует ассоциативный массив следующим образом:

$data = array('test'=>'val', 'foo'=>'bar');

на

{"test": "val", "foo": "bar"}

который является просто объектом JavaScript (так как в JS нет ассоциативных массивов (строго говоря)).

во-первых, я хочу сказать спасибо всем, кто ответил на мой вопрос. Я очень ценю все ваши ответы.

Что касается этого вопроса, я провел некоторые дальнейшие исследования, запустив некоторые тесты. Разбор происходит в браузере. IE 8-это единственный браузер, который не имеет собственного парсера JSON. XML-это те же данные, что и версия JSON.

Chrome (версия 8.0.552.224), JSON: 92ms, XML: 90ms

Firefox (версия 3.6.13), JSON: 65ms, XML: 129ms

IE (версия 8.0.6001.18702), JSON: 172ms, XML: 125ms

интересно, что Chrome, кажется, имеет почти такую же скорость. Обратите внимание, что это разбор большого количества данных. С небольшими фрагментами данных, это, вероятно, не такое уж большое дело.

тесты были сделаны. вот. Разница в некоторых из более ранних браузеров оказалась целым порядком величины (порядка 10 миллисекунд вместо 100 мс), но не массивной. Часть этого находится во времени ответа сервера-XML является более громоздким как формат данных. Часть его-время синтаксического анализа-JSON позволяет отправлять объекты JavaScript, в то время как XML требует синтаксического анализа документа.

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

см. также вопрос SO когда предпочитают формате JSON по сравнению с XML?

производительность на самом деле не является соображением, предполагая, что вы не говорите о гигабайтах XML. Да, это займет больше времени (XML более подробный), но это не будет то, что пользователь заметит.

реальная проблема, на мой взгляд, это поддержка XML в JavaScript. E4X приятно, но это не поддерживается Microsoft. Поэтому вам нужно будет использовать стороннюю библиотеку (например, JQuery) для анализа XML.

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

Зачем измерять? Поскольку спекуляция, основанная исключительно на свойствах форматов данных, не очень полезна для анализа производительности-интуиция разработчиков, как известно, плохо предсказывает производительность. В этом случае это просто означает, что все сводится к погашению соответствующие XML и JSON парсер (и генераторы) в использовании. XML имеет то преимущество, что он был дольше; JSON немного проще в обработке. Это основано на том, что на самом деле написаны библиотеки для обработки обоих. В конце концов, если все равны (зрелость и оптимизации работы библиотек), JSON может быть немного быстрее. Но оба могут быть очень быстрыми; или очень медленными с плохими реализациями.

: Я подозреваю, что вы не должны беспокоиться так много о спектакль, как многие уже предлагали. И xml и json могут быть проанализированы эффективно, и с современными браузерами, вероятно, есть. Скорее всего, если у вас есть проблемы с производительностью, это не чтение или запись данных, а что-то еще; и первым шагом будет на самом деле выяснить, в чем заключается фактическая проблема.

поскольку JSON является родным и предназначен для Javascript, он будет выполнять синтаксический анализ XML в течение всего дня. вы не упомянули свой серверный язык, в PHP есть функциональность json_encode/json_decode, встроенная в ядро PHP...

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

но, чтобы ответить на вопрос ayou: JSON будет быстрее анализировать (потому что это простая нотация объектов javascript).

в этой ситуации, я бы сказал, придерживаться XML. Все основные браузеры имеют интерфейс синтаксического анализа DOM, который будет анализировать хорошо сформированный XML. Эта ссылка показывает способ использования DOMParser интерфейс в Webkit / Opera / Firefox, а также объект ActiveX DOM в IE: https://sites.google.com/a/van-steenbeek.net/archive/explorer_domparser_parsefromstring

Это также зависит от того, как ваш JSON структурирован. Древовидные структуры, как правило, анализируются более эффективно, чем список объектов. Именно здесь будет полезно фундаментальное понимание структур данных. Я не удивлюсь, если вы проанализируете структуру списка в JSON, которая может выглядеть так:

{
        {
            "name": "New York",
            "country":"USA",
            "lon": -73.948753,
            "lat": 40.712784
        },
        {
            "name": "Chicago",
            "country":"USA",
            "lon": -23.948753,
            "lat": 20.712784
        },
        {
            "name": "London",
            "country":"UK",
            "lon": -13.948753,
            "lat": 10.712784
        }
}

а затем сравните его с древовидной структурой в XML, которая может выглядеть так:

<cities>
  <country name="USA">
     <city name="New York">
        <long>-73.948753</long>
        <lat>40.712784</lat>
     </city>
     <city name="Chicago">
        <long>-23.948753</long>
        <lat>20.712784</lat>
     </city>
  </country>
 <country name="UK">
     <city name="London">
        <long>-13.948753</long>
        <lat>10.712784</lat>
     </city>
  </country>
</cities>

структура XML может дать более быстрое время, чем у JSON так как если я петлю через узел Великобритании, чтобы найти Лондон, мне не нужно петлять через остальные страны, чтобы найти мой город. В Примере JSON я просто могу, если Лондон находится в нижней части списка. Но, то, что мы имеем здесь-это разница в структуре. Я был бы удивлен, обнаружив, что XML быстрее в любом случае или в случае, когда структуры точно такие же.

здесь это эксперимент, который я сделал с помощью Python - я знаю, что вопрос смотрит на это строго с точки зрения JavaScript, но вы можете найти его полезным. Результаты показывают, что JSON быстрее, чем XML. Однако дело в том, что то, как вы структурируете, будет влиять на то, насколько эффективно вы можете его получить.

разбор или построение json сравнительно легко, чем xml, а также большинство языков предоставляют методы для более легкого кодирования и декодирования json, который несколько сложен с xml.

лучший пример, который я нашел об этих двух это :

http://www.utilities-online.info/xmltojson/#.VVGOlfCYK7M

Это означает, что JSON более удобочитаем и понятен для человека, чем XML.