From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
08-09-2011 07:01 PM
I have also had experience with slow math scripts. I was using a custom data fitting algorithm which I wrote in matlab. The labview program would read in 1550 points from the digitizer and pass it to the fitting algorithm. We wrote two versions of the fitting, one in the math script and another in native labview.
I forget the exact numbers, but I think the math script was slower but within a factor of 2.
08-10-2011 10:37 AM
Hi Blee66,
We are constantly striving to improve MathScript performance and appreciate any opportunity to inspect code that doesn't run well in MathScript. Often times there are small optimizations and improvements to the way code is written in MathScript that many people are unaware of. Would you be willing to post both your versions of the code so that we can compare and suggest improvements?
Thanks,
K Scott
08-10-2011 02:35 PM
I am Blee66's colleage, and was responsible for translating the Math Script code into native Labview. I have attached the VI with the fitting algorithm that we were using; the two versions are in the two panes of a diagram disable structure.
08-11-2011 11:08 AM
Hi jtay,
Could you post back a VI that contains some valid default values for the front panel inputs?
So far we have found two things that you may wish to change and profile again:
1) Turn off debugging on the VI. When debugging is on MathScript will take a greater hit to performance than native LabVIEW will.
2) Change the first_point input to an integer. If first_point is a double, then when you calulate N=last_point-first_point+1, you cause N to be a double. If N is a double then in line 76 when you calculate aN=a^N you will cause aN to become a complex number which will affect a large number of your later operations. Changing first_point to be an integer ensures that N is an integer and changes all the complex operations back to real numbers. You can validate this by turning on data type highlighting for the node and observing the variables change datatypes as you interact with the script.
If you post back some valid input numbers we can probably profile the code further.
Cheers!
K Scott
08-11-2011 11:49 AM
Here's the VI with some appropriate default values. And thanks for the suggestions for speeding up the math script. I had no idea that complex numbers were being calculated.
08-15-2011 03:59 PM
Hi Jtay,
I have attached your VI with a timing loop and a sequence structure we used for some basic profiling. This VI still contains your original LabVIEW code as well as your original MathScript code as well as our improved MathScript code. You should be able to diff the two MathScripts to view in detail the changes we made to the scripts themselves.
We were able to improve aproximately 7X on your original script by changing certain inputs to I32 and some vectorizing on the while and for loops. For some more info on vectorizing while/for loops there are interesting reads that you can search for on Google. You should know that this is still slightly slower than your native LabVIEW code and that is because we are forced to do more checking at runtime and there is a little more overhead associated with MathScript that LabVIEW doesn't have to deal with since MathScript is implementing a dynamically typed language for compatibility reasons. I think you will find that the added clarity and readability of your code should be more than enough reason to continue using MathScript and we hope to continue improving MathScript's relative performance to LabVIEW in the future.
Thanks for the opportunity to view how our customers are using MathScript "in the wild"!
K Scott
08-17-2011 11:38 AM
Could you provide a copy of the code you modified for Labview 2010? I can't open the one that you posted since it's saved in the 2011 version.
Thanks for the help.
08-17-2011 03:34 PM
I'm sory about that. Attached is the 2010 version. Note: you may have to reattach your subVIs if you wish to compare numbers with your LabVIEW code. I am uncertain they are linked properly since I had multiple versions and copies spread out on my machine.
Cheers!
K Scott