Javascript 解析 JSON 比解析 XML 快

Is parsing JSON faster than parsing XML

提问by geme_hendrix

I'm creating a sophisticated JavaScript library for working with my company's server side framework.

我正在创建一个复杂的 JavaScript 库来使用我公司的服务器端框架。

The server side framework encodes its data to a simple XML format. There's no fancy namespacing or anything like that.

服务器端框架将其数据编码为简单的 XML 格式。没有花哨的命名空间或类似的东西。

Ideally I'd like to parse all of the data in the browser as JSON. However, if I do this I need to rewrite some of the server side code to also spit out JSON. This is a pain because we have public APIs that I can't easily change.

理想情况下，我想将浏览器中的所有数据解析为 JSON。但是，如果我这样做，我需要重写一些服务器端代码来输出 JSON。这很痛苦，因为我们有无法轻易更改的公共 API。

What I'm really concerned about here is performance in the browser of parsing JSON versus XML. Is there really a big difference to be concerned about? Or should I exclusively go for JSON? Does anyone have any experience or benchmarks in the performance difference between the two?

我真正关心的是浏览器中解析 JSON 与 XML 的性能。真的有很大的不同需要关注吗？还是我应该专门使用 JSON？有没有人对两者之间的性能差异有任何经验或基准？

I realize that most modern web developers would probably opt for JSON and I can see why. However, I really am just interested in performance. If there's a proven massive difference then I'm prepared to spend the extra effort in generating JSON server side for the client.

我意识到大多数现代 Web 开发人员可能会选择 JSON，我明白为什么。然而，我真的只是对性能感兴趣。如果证明存在巨大差异，那么我准备花费额外的精力为客户端生成 JSON 服务器端。

采纳答案by treeface

JSON should be faster since it's JSObject Notation, which means it can be recognized natively by JavaScript. In PHP on the GET side of things, I will often do something like this:

JSON 应该更快，因为它是JSObject Notation，这意味着它可以被 JavaScript 本地识别。在 GET 方面的 PHP 中，我经常会做这样的事情：

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

For more information on this, see here:

有关这方面的更多信息，请参见此处：

Why is Everyone Choosing JSON Over XML for jQuery?

为什么每个人都为 jQuery 选择 JSON 而不是 XML？

Also...what "extra effort" do you really have to put into "generating" JSON? Surely you can't be saying that you'll be manually building the JSON string? Almost every modern server-side language has libraries that convert native variables into JSON strings. For example, PHP's core json_encodefunction converts an associative array like this:

另外......你真的需要付出什么“额外的努力”来“生成”JSON？您肯定不能说您将手动构建 JSON 字符串吗？几乎所有现代服务器端语言都有将本机变量转换为 JSON 字符串的库。例如，PHP 的核心json_encode函数像这样转换关联数组：

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

into

进入

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

Which is simply a JavaScript object (since there are no associative arrays (strictly speaking) in JS).

这只是一个 JavaScript 对象（因为在 JS 中没有关联数组（严格来说））。

回答by geme_hendrix

Firstly, I'd like to say thanks to everyone who's answered my question. I REALLY appreciate all of your responses.

首先，我要感谢所有回答我问题的人。我真的很感谢你的所有回应。

In regards to this question, I've conducted some further research by running some benchmarks. The parsing happens in the browser. IE 8 is the only browser that doesn't have a native JSON parser. The XML is the same data as the JSON version.

关于这个问题，我通过运行一些基准进行了一些进一步的研究。解析发生在浏览器中。IE 8 是唯一没有原生 JSON 解析器的浏览器。XML 是与 JSON 版本相同的数据。

Chrome (version 8.0.552.224), JSON: 92ms, XML: 90ms

Chrome（版本 8.0.552.224），JSON：92 毫秒，XML：90 毫秒

Firefox (version 3.6.13), JSON: 65ms, XML: 129ms

Firefox（版本 3.6.13），JSON：65 毫秒，XML：129 毫秒

IE (version 8.0.6001.18702), JSON: 172ms, XML: 125ms

IE（版本 8.0.6001.18702），JSON：172ms，XML：125ms

Interestingly, Chrome seems to have almost the same speed. Please note, this is parsing a lot of data. With little snippets of data, this isn't probably such a big deal.

有趣的是，Chrome 似乎具有几乎相同的速度。请注意，这是解析大量数据。有了很少的数据片段，这可能不是什么大问题。

回答by justkt

Benchmarks have been done. Here's one. The difference in some of the earlier browsers appeared to be an entire order of magnitude (on the order of 10s of milliseconds instead of 100s of ms), but not massive. Part of this is in server response time - XML is bulkier as a data format. Part of it is parsing time - JSON lets you send JavaScript objects, while XML requires parsing a document.

基准已经完成。 这是一个。一些早期浏览器的差异似乎是一个完整的数量级（大约 10 毫秒而不是 100 毫秒），但不是很大。部分原因在于服务器响应时间——XML 作为一种数据格式更为庞大。一部分是解析时间——JSON 允许您发送 JavaScript 对象，而 XML 需要解析文档。

You could consider adding to your public API a method to return JSON instead of modifying existing functions if it becomes and issue, unless you don't want to expose the JSON.

您可以考虑向您的公共 API 添加一个返回 JSON 的方法，而不是修改现有函数（如果它成为并发出），除非您不想公开 JSON。

See also the SO question When to prefer JSON over XML?

另请参阅 SO 问题何时更喜欢 JSON 而不是 XML？

回答by Anon

Performance isn't really a consideration, assuming that you're not talking about gigabytes of XML. Yes, it will take longer (XML is more verbose), but it's not going to be something that the user will notice.

性能并不是真正的考虑因素，假设您不是在谈论千兆字节的 XML。是的，它需要更长的时间（XML 更冗长），但用户不会注意到它。

The real issue, in my opinion, is support for XML within JavaScript. E4Xis nice, but it isn't supported by Microsoft. So you'll need to use a third-party library (such as JQuery) to parse the XML.

在我看来，真正的问题是 JavaScript 中对 XML 的支持。E4X很好，但它不受 Microsoft 支持。因此，您需要使用第三方库（例如 JQuery）来解析 XML。

回答by StaxMan

If possible, it would make sense to just measure it. By 'if possible' I mean that tooling for javascript (esp. for performance analysis) may not be quite as good as for stand-alone programming languages.

如果可能，只测量它是有意义的。“如果可能”我的意思是 javascript 工具（尤其是性能分析）可能不如独立编程语言好。

Why measure? Because speculation based solely on properties of data formats is not very useful for performance analysis -- developers' intuitions are notoriously poor at predicting performance. In this case it just means that it all comes down to maturity of respective XML and JSON parser (and generators) in use. XML has the benefit of having been around longer; JSON is bit simpler to process. This based on having actually written libraries for processing both. In the end, if all things are equal (maturity and performance optimization of libraries), JSON can indeed be bit faster to process. But both can be very fast; or very slow with bad implementations.

为什么要测量？因为仅基于数据格式属性的推测对于性能分析不是很有用——众所周知，开发人员的直觉在预测性能方面很差。在这种情况下，它只是意味着这一切都归结为各自使用的 XML 和 JSON 解析器（和生成器）的成熟度。XML 的优点是存在时间更长；JSON 处理起来更简单一些。这基于实际编写了用于处理两者的库。最后，如果一切都一样（库的成熟度和性能优化），JSON 的处理速度确实可以快一点。但两者都可以非常快；或者很慢，执行不好。

However: I suspect that you should not worry all that much about performance, like many have already suggested. Both xml and json can be parsed efficiently, and with modern browsers, probably are. Chances are that if you have performance problems it is not with reading or writing of data but something else; and first step would be actually figuring out what the actual problem is.

但是：我怀疑您不应该太担心性能，就像许多人已经建议的那样。xml 和 json 都可以有效地解析，并且使用现代浏览器，可能是。很有可能，如果您遇到性能问题，不是因为读取或写入数据，而是其他问题；第一步实际上是弄清楚实际问题是什么。

回答by Alex Vidal

In this situation, I'd say stick with the XML. All major browsers have a DOM parsing interface that will parse well-formed XML. This link shows a way to use the DOMParserinterface in Webkit/Opera/Firefox, as well as the ActiveX DOM Object in IE: https://sites.google.com/a/van-steenbeek.net/archive/explorer_domparser_parsefromstring

在这种情况下，我会说坚持使用 XML。所有主要浏览器都有一个 DOM 解析接口，可以解析格式良好的 XML。此链接显示了DOMParser在 Webkit/Opera/Firefox 中使用界面的方法，以及在 IE 中使用 ActiveX DOM 对象的方法：https: //sites.google.com/a/van-steenbeek.net/archive/explorer_domparser_parsefromstring

回答by Mr. Concolato

It also depends on how your JSON is structured. Tree-like structures tend to parse more efficiently than a list of objects. This is where one's fundamental understanding of data structures will be handy. I would not be surprised if you parse a list-like structure in JSON that might look like this:

它还取决于您的 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
        }
}

and then compare it to a tree like structure in XML that might look like this:

然后将其与 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>

The XML structure may yield a faster time than that of JSON since if I loop through the node of UK to find London, I don't have to loop through the rest of the countries to find my city. In the JSON example, I just might if London is near the bottom of the list. But, what we have here is a difference in structure. I would be surprised to find that XML is faster in either case or in a case where the structures are exactly the same.

XML 结构可能会产生比 JSON 更快的时间，因为如果我循环遍历 UK 节点来查找伦敦，我不必遍历其他国家/地区来查找我的城市。在 JSON 示例中，如果伦敦靠近列表底部，我可能会这样做。但是，我们在这里看到的是结构上的差异。我会惊讶地发现 XML 在任何一种情况下或在结构完全相同的情况下都更快。

Hereis an experiment I did using Python - I know the question is looking at this strictly from a JavaScript perspective, but you might find it useful. The results show that JSON is faster than XML. However, the point is: how you structure is going to have an effect on how efficiently you are able to retrieve it.

这是我使用 Python 做的一个实验——我知道这个问题是从 JavaScript 的角度严格地看待这个问题，但你可能会发现它很有用。结果表明，JSON 比 XML 快。但是，关键是：您的结构方式将影响您检索它的效率。

回答by FatherStorm

since JSON is native in and designed FOR Javascript, it's going to out-perform XML parsing all day long. you didn't mention your server-side language, in PHP there is the json_encode/json_decode functionality built into the PHP core...

由于 JSON 是原生的并且是为 Javascript 设计的，因此它整天都将胜过 XML 解析。您没有提到您的服务器端语言，在 PHP 中，PHP 核心内置了 json_encode/json_decode 功能...

回答by oezi

the difference in performace will be so tiny, you wouldn't even notice it (and: you shouldn't think about performance problems until you haveperformance problems - there are a lot of more important points to care for - maintainable, readable and documented code...).

在服务表现差异会如此的渺小，你甚至不会注意到它（和：你不应该考虑性能问题，直到您有性能问题-有很多更重要的点照顾-维护，可读性和记录代码...）。

but, to answer ayou question: JSON will be faster to parse (because it's simple javascript object notation).

但是，要回答一个问题：JSON 的解析速度会更快（因为它是简单的 javascript 对象表示法）。

回答by BitTickler

Another reason to stick with XML is, that if you switch to JSON, you modify the "maintenance contract". XML is more typed than JSON is, in the sense that it works more naturally with typed languages (i.e. NOT javascript).

坚持使用 XML 的另一个原因是，如果您切换到 JSON，则会修改“维护合同”。XML 比 JSON 更具类型化，因为它更自然地与类型化语言（即不是 javascript）一起工作。

If you change to JSON, some future maintainer of the code base might introduce a JSON array at some point which has mixed type content (e.g. [ "Hello", 42, false ]), which will present a problem to any code written in a typed language.

如果您更改为 JSON，则代码库的某些未来维护者可能会在某个时候引入一个 JSON 数组，该数组具有混合类型内容（例如[ "Hello", 42, false ]），这会给以类型语言编写的任何代码带来问题。

Yes, you could do that as well in XML but it requires extra effort, while in JSON it can just slip in.

是的，您也可以在 XML 中做到这一点，但这需要额外的努力，而在 JSON 中，它可以直接插入。

And while it does not seem like a big deal at first glance, it actually is as it forces the code in the typed language to stick with a JSON tree instead of deserializing to a native type.

虽然乍一看似乎没什么大不了的，但它实际上是因为它强制类型化语言中的代码坚持使用 JSON 树，而不是反序列化为本机类型。