Разбирает JSON быстрее, чем разбор XML - PullRequest
54 голосов
/ 04 января 2011

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

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

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

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

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

Ответы [ 12 ]

29 голосов
/ 04 января 2011

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');
* +1015 * в
{"test": "val", "foo": "bar"}

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

19 голосов
/ 06 января 2011

Во-первых, я хотел бы сказать спасибо всем, кто ответил на мой вопрос.Я ДЕЙСТВИТЕЛЬНО ценю все ваши ответы.

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

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

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

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

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

8 голосов
/ 04 января 2011

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

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

См. Также вопрос SO Когда предпочитать JSON XML?

4 голосов
/ 04 января 2011

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

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

2 голосов
/ 04 января 2011

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

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

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

1 голос
/ 28 декабря 2014

Это также зависит от структуры вашего 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. Однако дело в том, как ваша структура будет влиять на эффективность ее извлечения.

1 голос
/ 04 января 2011

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

1 голос
/ 04 января 2011

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

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

1 голос
/ 04 января 2011

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

0 голосов
/ 24 апреля 2019

Другая причина придерживаться XML заключается в том, что если вы переключаетесь на JSON, вы изменяете «контракт на обслуживание».XML более типизирован, чем JSON, в том смысле, что он более естественно работает с типизированными языками (т.е. НЕ javascript).

Если вы перейдете на JSON, какой-нибудь будущий сопровождающий базы кода может представить массив JSON внекоторая точка со смешанным типом содержимого (например, [ "Hello", 42, false ]), которая будет представлять проблему для любого кода, написанного на типизированном языке.

Да, вы можете сделать это также в XML, но это требует дополнительных усилий,в то время как в JSON он может просто проскальзывать.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...