04-08-2016 02:10 PM - edited 04-08-2016 02:19 PM
I was recently benchmarking the "Read From XML" VI to troubleshoot a performance problem I am having, and I have found some really odd behavior.
If I generate a large array of clusters, using the code below, the performance is quite acceptable. "Read From XML" takes around 70 ms to process a 4900 element array:
Here are charts of the execution time versus array size, and character count versus array size:
The performance of "Read From XML" drops by orders of magnitude if I encapsulate the array of clusters inside another cluster, like shown:
The execution time versus the number of elements, and the string length are below:
So while the string length is essentially identical between the two files, the execution time is 70 times slower, taking almost 5 seconds to process a 4900 element array, when a cluster encapsulates the array. "Unflatten from XML," "Flatten To XML," and "Write XML" all perform well in both cases.
Is there any explanation for this performance hiccup, or tricks to circumvent it?
04-08-2016 03:18 PM
04-08-2016 03:37 PM
Read from XML isn't supposed to be navigating the entire tree structure though, AFAIK. It just returns the string contents of <LVData> with the <version> tag removed. It shouldnt need to look any deeper than top level tags. Unflatten from XML, which then processes the document, scales just fine in both cases.
04-08-2016 03:56 PM
@ngarneski wrote:Read from XML isn't supposed to be navigating the entire tree structure though, AFAIK. It just returns the string contents of <LVData> with the <version> tag removed. It shouldnt need to look any deeper than top level tags. Unflatten from XML, which then processes the document, scales just fine in both cases.
Open the block diagram of Read From XML File(string) and look at the vi called ParseXMLFragments.vi, this vi navigates the whole tree structure.
Ben64