slow execution speed

[Travis]

I'm doing some work right now where this XML tool would be very handy. I'm trying it out with the demo package, but I'm suffering some really slow execution speeds; like, we're talking 2 minutes to open a roughly 1 MB TCX file. For my application, this is a very small file.

 

I tried splitting up the parsing into 2 separate chunks, but that didn't make a big enough difference. In my case, it took 2min 6s to execute the Easy Parse XML when doing the full parsing, and it still took 1min 42s to execute the method where I divided the task into two parts. Faster, but not nearly fast enough.

 

Is there anything you can do in your implementation to speed up execution times? I would really like to use the EasyXML because it would save a lot of work and we have other XML-related things we would like to do.

 

The attached VI is version 8.5

 

Thanks,

 

Travis

test_TCX_read.zip

[Jim Kring]

Travis,

 

First, thank you for taking the time to evaluate EasyXML. I'm happy to hear that you like its usability features. As this is our first release, we focused more on getting it working than on performance optimization. Certainly 2 minutes is way too long. Let me take a look your example and see how we can improve the performance.

 

Thanks,

 

-Jim Kring

[Travis]

Travis,

 

First, thank you for taking the time to evaluate EasyXML. I'm happy to hear that you like its usability features. As this is our first release, we focused more on getting it working than on performance optimization. Certainly 2 minutes is way too long. Let me take a look your example and see how we can improve the performance.

 

Thanks,

 

-Jim Kring

 

Thanks for looking into the speed. I do like the functionality and it would be really nice to be able to use it in our application.

 

Travis

[Travis]

Here's something I thought I would throw out there. When I upgraded from 8.2.1 to 8.5, I found a wierd performance issue with 8.5 in one of my VIs. In 8.2.1 I had a VI where I used a case structure within two nested for loops that ran plenty fast; however, when I upgraded to 8.5 that same VI ran more than an order of magnitude slower. I coudn't find a good reason for it to happen. I tried recompiling and even tried making the VI from scratch again. The odd odd thing about this 8.5 performance issue is that it was a problem under both Windows and MacOS. I got around the issue by replacing the case structure with select node and drove on, but I made a note to go back and try to figure out what the deal was and never got around to it.

 

I'm just bringing this up because it seems possible that your implementation might make use of case structures within nested loops. The easy way to see if this is the issue would be to check the execution speed in 8.2.1. I would do it myself, but I don't have it installed anywhere anymore.

 

Travis

[JKI]

Here's something I thought I would throw out there. When I upgraded from 8.2.1 to 8.5, I found a wierd performance issue with 8.5 in one of my VIs. In 8.2.1 I had a VI where I used a case structure within two nested for loops that ran plenty fast; however, when I upgraded to 8.5 that same VI ran more than an order of magnitude slower. I coudn't find a good reason for it to happen. I tried recompiling and even tried making the VI from scratch again. The odd odd thing about this 8.5 performance issue is that it was a problem under both Windows and MacOS. I got around the issue by replacing the case structure with select node and drove on, but I made a note to go back and try to figure out what the deal was and never got around to it.

 

I'm just bringing this up because it seems possible that your implementation might make use of case structures within nested loops. The easy way to see if this is the issue would be to check the execution speed in 8.2.1. I would do it myself, but I don't have it installed anywhere anymore.

 

Travis

 

That's interesting. I don't think that this issue (you described) is what's affecting us. I just ran your test VI (test TCX read.vi) in LabVIEW 7.1 through 8.5 and here's what I get:

 

LVver, Whole, Divide and Conquer

LV8.5, 00:38, 00:30

LV8.2, 00:53, 00:46

LV8.0, 00:36, 00:28

LV7.1, 00:41, 00:33

 

As you can see, LabVIEW 8.2 performs the worst, but the other versions (7.1, 8.0, and 8.5) seem to be roughly equivalent.

 

I'm still looking at the code to see what we can do to improve the performance -- I'm confident that we'll find a good solution, soon. Certainly, there is room for improvement

 

-Jim

[Jim Kring]

Travis,

 

Here's a quick update...

 

We've started doing some work to try to optimize the code, including rewriting the XML string parser, changing the data traversal routine from VI recursion to loop-stack and also looking into ways to improve the variant handling and parsing of the LabVIEW data+type descriptors. None of this work is trivial and will take a little time to get right. But, we're committed to getting EasyXML to perform to its full potential. We might not have an immediate solution to your large XML file issue, but we're working hard on it.

 

Thanks,

 

-Jim

[Travis]

Good news! I have already placed it in my application in hopes of a warp-speed version in the future.

 

I parsed a 20 mile ride Sunday that was a 2.3 MB TCX file. That one cycled through 4 or 5 of the demo package dialog messages before it loaded all the way. It seems to be slowing down faster than linear with size, so I hate to imagine what the 100 mile, 10+ MB ride files will do later this spring.

 

And I understand that I might be asking too much of a pacakge with "easy" in the name. I'm just hoping to be able to use it because it is so..... easy. I'm going to go ahead and order the package anyway because it is so enabling for smaller XML files that I'll actually start using XML format more for other applications.

 

Thanks,

 

Travis

[Travis]

How many machines can the single develop license be installed on? I've tried finding the answer in the docs but I'm not seeing it. I have 2 desktops and a laptop that I develop on and that's not counting the MacBook that I have to use for building the MacOS version of my app.

 

Thanks,

 

Travis

[Jim Kring]

Travis,

 

Thank you for your vote of confidence. We'll certainly work hard to keep improving EasyXML, and keep you as a happy customer

 

Regarding the licensing, it is a per-user license with no restrictions on the number of applications or computers on which it can be installed. We just ask that you have one license for each developer who is using EasyXML to create software.

 

Thanks,

 

-Jim

[Jim Kring]

Hi Travis,

 

Here's a another quick update:

 

We've made several optimizations and have gotten the time to execute your TCX read test case down to under 8 seconds (in LabVIEW 8.5 using the same machine that produced the stats in my previous post). The good news is also that the divide and conquer approach is only slightly faster (about 500ms).

 

Please don't take this as a promise or guarantee that we'll have a new, better-performing version out immediately, but I wanted to let you know that we are working hard on this issue and think we have a good solution. That said, we still need to do a lot of testing and some more fine-tuning -- this was a significant over-haul of the code.

 

Thanks,

 

-Jim

[Travis]

That's good news--sorry to cause the trouble. I'm looking forward to the upgrade when you are ready with it.

 

Even at 8 seconds, a fill bar would be nice if there is an easy way to provide it as an option.

 

Thanks,

 

Travis

[Jim Kring]

Even at 8 seconds, a fill bar would be nice if there is an easy way to provide it as an option.

 

That thought crossed my mind, too. We'll look into whether this is feasible.

 

Thanks,

 

-Jim

[Travis]

How's the optimization coming?

[Jim Kring]

How's the optimization coming?

 

Hi Travis,

 

It's going very well. We can't make any commitments as to when we will publicly release a new version. That said, if you would like to help us test out some of these improvements, please send us a message via our contact form. We appreciate your feedback and efforts as an early adoptor

 

Thanks,

 

-Jim

[Tim_C]

Hello - Was an updated version of EasyXML released with the optimizations mentioned in this thread? I'm seeing some relatively long execution times to read my XML file with EasyXML (currently about 20 seconds for a 65k file), and I expect this XML file to eventually become quite a bit larger. I'm running LabView 8.6.

 

Also, any tips on making XML file reads go faster, for example is the read time affected heavily by certain elements / arrangements of the data structure?

Thanks,

Tim

[Jim Kring]

Hello - Was an updated version of EasyXML released with the optimizations mentioned in this thread? I'm seeing some relatively long execution times to read my XML file with EasyXML (currently about 20 seconds for a 65k file), and I expect this XML file to eventually become quite a bit larger. I'm running LabView 8.6.

 

Also, any tips on making XML file reads go faster, for example is the read time affected heavily by certain elements / arrangements of the data structure?

Thanks,

Tim

 

Hi Tim,

 

We haven't released this improvement, yet. However, EasyXML customers can contact us for a pre-release version of the new version.

 

Thanks,

 

-Jim