解析JSON比解析XML快吗

时间:2022-12-01 11:23:12

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服务器端。

11 个解决方案

#1


31  

JSON should be faster since it's JS Object 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应该更快,因为它是JS对象表示法,这意味着它可以被JavaScript本地识别。在PHP的GET方面,我通常会这样做:

<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_encode function 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中没有关联数组(严格来说))。

#2


18  

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: 92ms, XML: 90ms

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

Firefox(3.6.13版本),JSON: 65ms, XML: 129ms

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的速度几乎相同。请注意,这是在解析大量数据。对于一小段数据,这可能不是什么大问题。

#3


8  

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.

基准测试已经完成。这是一个。一些早期的浏览器的不同之处在于它是一个完整的数量级(以毫秒为单位,而不是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?

#4


4  

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. E4X is 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很好,但是它不受微软的支持。因此,您需要使用第三方库(如JQuery)来解析XML。

#5


2  

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功能……

#6


2  

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都可以被有效地解析,现代浏览器可能也是如此。如果你有一些性能问题,那就不是阅读或写数据,而是别的什么;第一步就是找出真正的问题是什么。

#7


1  

the difference in performace will be so tiny, you wouldn't even notice it (and: you shouldn't think about performance problems until you have performance 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对象表示法)。

#8


1  

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 DOMParser interface 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。这个链接显示了在Webkit/Opera/Firefox中使用DOMParser接口的方法,以及IE中的ActiveX DOM对象:https://sites.google.com/a/van-steenbeek.net/archive/explorer_domparser_parsefromstring

#9


1  

Parsing or constructing json is comparatively easy than an xml and also most of the languages provide methods for easier encoding and decoding of json which is somewhat complex with xml.

解析或构造json相对来说比xml简单,而且大多数语言都提供了更容易编码和解码json的方法,这在xml中有点复杂。

#10


1  

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产生更快的时间,因为如果我遍历英国的节点来找到伦敦,我不需要遍历其他国家来找到我的城市。在JSON示例中,如果伦敦接近列表底部,我可能会这样做。但是,这里的结构是不同的。我可能会惊讶地发现,无论是在哪种情况下,XML都更快,或者在结构完全相同的情况下。

Here is 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快。然而,关键是:你的结构将会对你如何有效地检索它产生影响。

#11


1  

best example i have found about these two is :

关于这两个问题,我找到的最好的例子是:

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

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

that means JSON is more human readable and understandable than XML.

这意味着JSON比XML更具可读性和可理解性。

#1


31  

JSON should be faster since it's JS Object 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应该更快,因为它是JS对象表示法,这意味着它可以被JavaScript本地识别。在PHP的GET方面,我通常会这样做:

<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_encode function 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中没有关联数组(严格来说))。

#2


18  

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: 92ms, XML: 90ms

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

Firefox(3.6.13版本),JSON: 65ms, XML: 129ms

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的速度几乎相同。请注意,这是在解析大量数据。对于一小段数据,这可能不是什么大问题。

#3


8  

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.

基准测试已经完成。这是一个。一些早期的浏览器的不同之处在于它是一个完整的数量级(以毫秒为单位,而不是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?

#4


4  

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. E4X is 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很好,但是它不受微软的支持。因此,您需要使用第三方库(如JQuery)来解析XML。

#5


2  

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功能……

#6


2  

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都可以被有效地解析,现代浏览器可能也是如此。如果你有一些性能问题,那就不是阅读或写数据,而是别的什么;第一步就是找出真正的问题是什么。

#7


1  

the difference in performace will be so tiny, you wouldn't even notice it (and: you shouldn't think about performance problems until you have performance 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对象表示法)。

#8


1  

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 DOMParser interface 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。这个链接显示了在Webkit/Opera/Firefox中使用DOMParser接口的方法,以及IE中的ActiveX DOM对象:https://sites.google.com/a/van-steenbeek.net/archive/explorer_domparser_parsefromstring

#9


1  

Parsing or constructing json is comparatively easy than an xml and also most of the languages provide methods for easier encoding and decoding of json which is somewhat complex with xml.

解析或构造json相对来说比xml简单,而且大多数语言都提供了更容易编码和解码json的方法,这在xml中有点复杂。

#10


1  

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产生更快的时间,因为如果我遍历英国的节点来找到伦敦,我不需要遍历其他国家来找到我的城市。在JSON示例中,如果伦敦接近列表底部,我可能会这样做。但是,这里的结构是不同的。我可能会惊讶地发现,无论是在哪种情况下,XML都更快,或者在结构完全相同的情况下。

Here is 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快。然而,关键是:你的结构将会对你如何有效地检索它产生影响。

#11


1  

best example i have found about these two is :

关于这两个问题,我找到的最好的例子是:

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

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

that means JSON is more human readable and understandable than XML.

这意味着JSON比XML更具可读性和可理解性。