XML 구문 분석보다 JSON 구문 분석이 더 빠릅니다.
우리 회사의 서버 측 프레임 워크를 사용하기위한 정교한 JavaScript 라이브러리를 만들고 있습니다.
서버 측 프레임 워크는 데이터를 간단한 XML 형식으로 인코딩합니다. 멋진 네임 스페이스 나 그런 것은 없습니다.
이상적으로는 브라우저의 모든 데이터를 JSON으로 구문 분석하고 싶습니다. 그러나 이렇게하면 서버 측 코드 중 일부를 다시 작성하여 JSON도 뱉어 내야합니다. 쉽게 변경할 수없는 공용 API가 있기 때문에 이것은 고통입니다.
여기서 제가 정말로 염려하는 것은 JSON과 XML을 구문 분석하는 브라우저의 성능입니다. 걱정해야 할 큰 차이가 있습니까? 아니면 JSON 만 사용해야합니까? 누구든지 둘 사이의 성능 차이에 대한 경험이나 벤치 마크가 있습니까?
나는 대부분의 현대 웹 개발자가 아마도 JSON을 선택할 것이라는 것을 알고 있으며 그 이유를 알 수 있습니다. 그러나 나는 정말로 성능에만 관심이 있습니다. 입증 된 엄청난 차이가 있다면 클라이언트를 위해 JSON 서버 측을 생성하는 데 추가 노력을 기울일 준비가 된 것입니다.
JSON은 자바 스크립트에서 기본적으로 인식 할 수있는 JS Object Notation 이기 때문에 더 빨라야합니다 . GET 쪽의 PHP에서는 종종 다음과 같은 작업을 수행합니다.
<script type="text/javascript">
var data = <?php json_encode($data)?>;
</script>
이에 대한 자세한 내용은 여기를 참조하십시오.
모두가 jQuery를 위해 XML 대신 JSON을 선택하는 이유는 무엇입니까?
또한 ... 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의 속도는 거의 같은 것 같습니다. 이것은 많은 데이터를 구문 분석하는 것입니다. 작은 데이터 조각만으로는 그렇게 큰 문제가 아닐 것입니다.
벤치 마크가 완료되었습니다. 여기에 하나 입니다. 일부 이전 브라우저의 차이는 전체 크기 (100 밀리 초가 아닌 10 밀리 초 단위)로 보였지만 크지 않았습니다. 이 중 일부는 서버 응답 시간에 있습니다. XML은 데이터 형식으로 더 부피가 커집니다. 그 중 일부는 파싱 시간입니다. JSON을 사용하면 JavaScript 객체를 보낼 수 있지만 XML은 문서를 파싱해야합니다.
JSON을 노출하지 않으려는 경우가 아니라면 기존 함수가 발생하고 문제가 발생하면 수정하는 대신 JSON을 반환하는 메서드를 공용 API에 추가하는 것을 고려할 수 있습니다.
SO 질문 언제 XML보다 JSON을 선호할까요?
기가 바이트의 XML에 대해 이야기하고 있지 않다고 가정하면 성능은 실제로 고려 사항이 아닙니다. 예, 시간이 더 오래 걸리지 만 (XML이 더 장황함) 사용자가 눈치 채지 못할 것입니다.
제 생각에 진짜 문제는 JavaScript 내에서 XML을 지원하는 것입니다. E4X 는 훌륭하지만 Microsoft에서 지원하지 않습니다. 따라서 XML을 구문 분석하려면 타사 라이브러리 (예 : JQuery)를 사용해야합니다.
가능하다면 측정 만하는 것이 좋습니다. '가능한 경우'는 자바 스크립트 (특히 성능 분석 용) 도구가 독립형 프로그래밍 언어만큼 좋지 않을 수 있음을 의미합니다.
왜 측정합니까? 오로지 데이터 형식의 속성에 기반한 추측은 성능 분석에 그다지 유용하지 않기 때문에 개발자의 직관은 성능을 예측하는 데 매우 열악합니다. 이 경우 모든 것이 사용중인 각 XML 및 JSON 파서 (및 생성기)의 성숙도에 달려 있음을 의미합니다. XML은 오래 사용되었다는 이점이 있습니다. JSON은 처리하기가 조금 더 간단합니다. 이것은 둘 다 처리하기 위해 실제로 작성된 라이브러리를 기반으로합니다. 결국 모든 것이 동일하다면 (라이브러리의 성숙도와 성능 최적화) JSON은 실제로 처리 속도가 조금 더 빠를 수 있습니다. 그러나 둘 다 매우 빠를 수 있습니다. 또는 잘못된 구현으로 매우 느립니다.
그러나 많은 사람들이 이미 제안한 것처럼 성능에 대해 그다지 걱정하지 말아야한다고 생각합니다. xml과 json은 모두 효율적으로 구문 분석 할 수 있으며 최신 브라우저에서는 아마도 그럴 것입니다. 성능 문제가있는 경우 데이터를 읽거나 쓰는 것이 아니라 다른 문제 일 가능성이 있습니다. 첫 번째 단계는 실제 문제가 무엇인지 실제로 파악하는 것입니다.
JSON은 기본적으로 Javascript 용으로 설계 되었기 때문에 하루 종일 XML 구문 분석을 능가 할 것입니다. 서버 측 언어에 대해서는 언급하지 않았습니다. PHP에는 PHP 코어에 내장 된 json_encode / json_decode 기능이 있습니다.
의 performace의 차이가 너무 작은 것입니다 당신도 그것을 통지 (그리고 것입니다 : 당신이 때까지 성능 문제에 대해 생각하지 말아야 가 성능 문제를 -, 유지 보수 읽을 수 문서화 - 더 중요한 포인트가 많이 돌보는있다 암호...).
그러나 당신의 질문에 대답하기 위해 : JSON은 파싱하는 것이 더 빠를 것입니다 (간단한 자바 스크립트 객체 표기법이기 때문에).
이 상황에서는 XML을 고수한다고 말하고 싶습니다. 모든 주요 브라우저에는 올바른 형식의 XML을 구문 분석하는 DOM 구문 분석 인터페이스가 있습니다. 이 링크는 DOMParser
Webkit / Opera / Firefox 의 인터페이스와 IE의 ActiveX DOM 개체 를 사용하는 방법을 보여줍니다 . 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이 두 경우 또는 구조가 정확히 동일한 경우 더 빠르다는 사실에 놀랄 것입니다.
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.
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.
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).
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.
Yes, you could do that as well in XML but it requires extra effort, while in JSON it can just slip in.
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.
best example i have found about these two is :
http://www.utilities-online.info/xmltojson/#.VVGOlfCYK7M
that means JSON is more human readable and understandable than XML.
ReferenceURL : https://stackoverflow.com/questions/4596465/is-parsing-json-faster-than-parsing-xml
'programing' 카테고리의 다른 글
뮤텍스는 어떻게 구현됩니까? (0) | 2021.01.15 |
---|---|
Eclipse의 유효한 HTML5 속성에 대한 경고 (0) | 2021.01.15 |
매개 변수가있는 ASP.NET MVC 3 클라이언트 쪽 유효성 검사 (0) | 2021.01.15 |
.net 응용 프로그램에서 SQL Server 시간 데이터 형식을 사용하는 방법은 무엇입니까? (0) | 2021.01.15 |
Android 데이터베이스를 온라인 SQL Server와 동기화하는 방법은 무엇입니까? (0) | 2021.01.15 |