Read from XML performance issues

[Norbert_B]

My best proposal:

Create a bunch of multiple XML files rather than a single monolithical one. This will simplify handling of file(s) by a great deal as long as filenames are distinctive but can be built automatically in a simple way.

Norbert

[PauldePaor]

---

P@Anand wrote:

I tried with 7 MB file and for that it took ~68 seconds to load and I can see how long it will take to load a file of around 200MB. How did you arrive at the Array of cluster? Is the other application you meant is also on LabVIEW platform?. I am not experienced with XML but trying what I can do.

---

The output from the XML file read is an array of clusters I then unbundle the elements I need from this cluster array format them inot seperate strings then rebuild the array and place them into a table

[Yamaeda]

That XML parsing is silly slow, luckily you dont need it! 🙂

That takes ~2 secs on my computer. You could half your old time by just using 1 of the XML parsers, they gave the same answer.

/Y

[Yamaeda]

I remember having xml performance issues in an old project, it seems the constant allocation by shuffling "after match" is very expensive. I think it's alot faster if you shuffle the "index after match" instead. It seems to be a horrible implementation of NI anyhow.

/Y

[P@Anand]

---

@Yamaeda wrote:

That XML parsing is silly slow, luckily you dont need it! 🙂

That takes ~2 secs on my computer. You could half your old time by just using 1 of the XML parsers, they gave the same answer.

/Y

---

You are too smart to find a way out of the box. Kudos 🙂

[JÞB]

The problem isn't with LabVIEW per se.  its a limitation of the Document Object Model  The XML Parser vis rely on the standard parser (DOMUserDefRef.dll) that all your browsers use. and loading the xml file like that can get nasty since DOMUserDefRef isn't thread safe so it runs in the UI Thread.  A Defer Panel Updates would help but is not a fix for files this size.

Luckilly the file follows the LabVIEW XML Schema Which supports only what LabVIEW data types exist.  So using Unflatten XML String can work VERY fast but it limits what applications can share the data to the subset of those that can understand the LabVIEW schema.

[Yamaeda]

---

@JÞB wrote:

The problem isn't with LabVIEW per se.  its a limitation of the Document Object Model  The XML Parser vis rely on the standard parser (DOMUserDefRef.dll) that all your browsers use. and loading the xml file like that can get nasty since DOMUserDefRef isn't thread safe so it runs in the UI Thread.  A Defer Panel Updates would help but is not a fix for files this size.

Luckilly the file follows the LabVIEW XML Schema Which supports only what LabVIEW data types exist.  So using Unflatten XML String can work VERY fast but it limits what applications can share the data to the subset of those that can understand the LabVIEW schema.

---

Actually the Read from XML only seems to use extensive use of regular expression nodes, no DLL.

/Y

[JÞB]

XML Parser vis. /Y

[Yamaeda]

Are we talking about the same VI's? In OP's vi he uses ReadFromXMLString with the following hierarchy:

No DLLs 🙂

/Y