JSON to Cluster faster than XML to Cluster?

[battler.]

Hi all,

We have been using XML to cluster/Cluster to XML for quite some time.

I've been recommended to start using JSON to cluster instead of XML because it's faster. Is this true?

Thoughts?

[GerdW]

Hi battler,

---

@battler. wrote:

I've been recommended to start using JSON to cluster instead of XML because it's faster. Is this true?

Thoughts?

---

Create a small benchmark code to convert your specific data to/from XML or JSON and compare the numbers on your own!

[battler.]

I thought someone more knowledgeable than I would know the answer or they could share their experience.

Furthermore this thread would be very beneficial for (possibly the very many) others still using XML.

@GerdW if you don't know the answer it's ok and if you can't be bothered finding out, even as a "Knight of NI", then really no need to comment like this!

[GerdW]

Hi battler,

---

@battler. wrote:

I thought someone more knowledgeable than I would know the answer or they could share their experience.

Furthermore this thread would be very beneficial for (possibly the very many) others still using XML.

@GerdW if you don't know the answer it's ok and if you can't be bothered finding out, even as a "Knight of NI", then really no need to comment like this!

---

I shared my experience when I wrote "convert your specific data to/from XML or JSON", but apparently you didn't get the point…

I marked the words "your specific data" because speed of  those conversion routines depends heavily on the specific datatype of your specific data! It's a huge difference if you want to convert a small cluster of just 3 items or a large array of heavily stacked clusters of different types! You also need to be careful about certain datatypes (maybe) not supported by the current JSON/XML implementation in LabVIEW (like timestamps?)!

Also be aware there are other XML/JSON conversion tools available in the VIPM, next to NI's implementation in LabVIEW…

So again I recommend:

Build your own small benchmark routine and use your specific datatypes to test conversion speeds to/from JSON/XML!

[battler.]

@GerdW I'm looking for specifics not generalities which you've just provided. I would like responses from others with experience in this specific topic.

I understand we can write a small test VI - and we are doing this. However, we are not hobbyists looking for a maybe answer to this as we need to make business decisions around the technical discussion supposed to be happening here which you've now hijacked.

[GerdW]

Hi battler,

---

@battler. wrote:

However, we are not hobbyists

---

Me neither…

---

@battler. wrote:

we need to make business decisions around the technical discussion supposed to be happening here

---

For this business decision: how important is LabVIEW execution speed for JSON/XML file handling? Is it the most important question for this business decision?

---

@battler. wrote:

I'm looking for specifics

---

Then you should test with your specific datatypes…

[alexderjuengere]

---

@battler. wrote:

@GerdW I'm looking for specifics not generalities which you've just provided. I would like responses from others with experience in this specific topic.

I understand we can write a small test VI - and we are doing this. However, we are not hobbyists looking for a maybe answer to this as we need to make business decisions around the technical discussion supposed to be happening here which you've now hijacked.

---

So, in what do you believe? a rumor from the internet - or your own Benchmark?

We are using both .vis (by the way, it is "flatten to json" not "cluster to json" ...) and never ran in any performance issues -

when turning on debbuging, the flatten json appears to be slower in some scenarios. (not shown in spoiler)

when the output of the function is meant to be rendered in a Frontpanel string indicator, the "flatten to json appears to be faster" - which is true for the following benchmark:

Spoiler

result	scenario	benchmark
slow
fast

[JÞB]

---

@battler. wrote:

Hi all,

We have been using XML to cluster/Cluster to XML for quite some time.

I've been recommended to start using JSON to cluster instead of XML because it's faster. Is this true?

Thoughts?

---

Let's ignore your snide comments.  Treating a cluster as a cluster is simply the fastest way to move data in LabVIEW.   So, the question becomes what do you want to exchange that data with?

• Full data to / from file or some serial interface?  Use binary files or flatten to string.
• Parts of the data? JSON has a hierarchical structure but doesn't mark up the data definitions in a schema
• All of the data where the LabVIEW Schema is sufficient? Use flatten to XML
• All of the data where the output must support a Document Object Model (W3C source) use to from XML but be ⚠️ warned W3C publishes DOMUSERDEFREF.DLL and it is not threadsafe. So, JSON might be faster but only for simple structures.

So, what is keeping you from developing benchmark code for your specific data and use case?  Those really matter! XML and JSON are different tools and you are asking which is a better Screw-hammer without finding out if the joint is screwed nailed glued or welded.

[proland1121]

Generally speaking, the native LabVIEW XML functions are indeed quite slow.  The XML parsing code posted here is about 90x faster than the native functions provided with NI (well, back when I benchmarked it vs LabVIEW 2017 anyway).

https://forums.ni.com/t5/Example-Code/Libxml2-Parsing-XML-in-LabVIEW-is-too-slow-or-is-it/ta-p/34926...

[Frozen]

---

@battler. wrote:

@GerdW I'm looking for specifics not generalities which you've just provided. I would like responses from others with experience in this specific topic.

---

If you want "specifics", I would have to agree with GerdW. The data being converted is specific to you and your company. YOU will have to do the comparison and decide which is best. The best anyone on the forums could do if give you generalities.

Your question in the first place makes me think... if the speed of data conversion to xml (or JSON) is an issue, you might have bigger problem... either coding or architecture.