Showing results for 
Search instead for 
Did you mean: 

Conversion of Labview Arrays to Matlab is slow



I'm using Labview with the Matlab script node. Large Arrays (500k elements) have to be transferred from LV to Matlab and back again. I found out that data conversion between these two programs takes approximately as long as my data evaluation in Matlab (see attached example with an exemplarily 2d-Fourier-transformation).


-Has anybody an idea how to speed up this convertion?

-How can I transfer arrays with 16bit resolution to Matlab without converting them to doubles?


Thank you



Download All
0 Kudos
Message 1 of 9



When LabVIEW executes a script node it needs to make an ActiveX call to communicate with the external application, so there is a significant amount of overhead that cannot really be avoided if you want to use a script node.  One alternative would be to use a MathScript Node, which uses the same m-file syntax.  An even better option would be to use the native FFT VI (located in the Signal Processing >> Transforms palette).  I know you are using the fft2 function just as an example, but there is a very good chance that LabVIEW provides the functionality you need either with the MathScript Node or with build-in VIs in the palettes.


Chris M 

Message 2 of 9

I agree with chris, use the plain FFT from the "signal processing...transforms" palette, it natively does 2D if you feed it a 2D array. It will easily be about an order of magnitude faster than your matlab version (not even counting the conversion time).


I suspect the mathscript version would be somewhere in-between in speed.

Message Edited by altenbach on 04-24-2009 09:12 AM
Message 3 of 9

Thank you Chris, thank you Altenbach,


finally I successfully translated all my (speed optimised) Matlab Code to Labview.

Here are the results:

-solution_1 (fastest): pure Labview code (with BLAS-components)

-solution_2 (medium): Labview with Matlab Script (The excecution of the Matlab Script is faster than in solution_1, but as mentioned the data conversion is very time consuming)

-solution_3 (unacceptable slow): Labview with MathScript node


Conclusion: Since the the conversion of large Labview arrays to Matlab takes such a long time, the power of Matlab (working with large matrices) can not reasonably combined with the power of Labview in all cases.





0 Kudos
Message 4 of 9



Which version of LabVIEW are you using?  I ask because MathScript is significantly faster with each new version of LabVIEW.  I still pure LabVIEW code would be your best bet, but the unacceptably slow performance of MathScript you are seeing may be due to using an older version of LabVIEW.


Chris M 

0 Kudos
Message 5 of 9

Hello Chris,


my comparison is based on Labview 8.6 and Matlab R2009a.



0 Kudos
Message 6 of 9



Just out of interest have you tried saving the arrays to a csv file and loading said file from within Matlab Script / Mathscript node?  I used to do this for large arrays and didnt notice to much performance hit.  But then again i wasnt really concerned with speed considering the test took about 24 Hrs anyway 😄


Probably slower than all the others but would be nice to hear if you had any luck with it.



Message Edited by craigc on 05-05-2009 11:42 AM
LabVIEW 2012
0 Kudos
Message 7 of 9



thank you for your proposal. My data amount which has to be transferred from Labview to Matlab is about 4MB. Astonishingly, writing (with LV) and reading (with Matlab) these data is only a little bit slower than transferring it directly via the Matlab node (400ms vs. 500ms). But since my data evaluation has to be done within 1000ms this order of magnitude is getting critical.

For comparison: The pure Labview solution (complete evaluation of data, stated as solution_1; see above) takes about 400ms. So I still prefer this one.



Message 8 of 9

Im not sure if I have just been doing things wrong, but I have noticed that the MathScript Node and even the Scilab Script Node seem to do very poorly with array indexing. I wrote a cubic spline function (LabVIEW's built in one is wayyyy too slow for me, I just think it is not optimized correctly) using both MathScript and Scilab Nodes (I did it with one, and then the other). In both cases it seemed to move much slower than expected. I turned on execution highlighting and saw that in the MathScript node it really slowed down when it hit the part where it had to continually index into the arrays. So what I did for debugging was replaced the assignment to the array index ( array[ i ] = computation ) with an assignment to just a scalar variable ( x = computation). The case with performing the computation and assigning the result to a variable (x = computation) was MUCH quicker than performing the computation and assigning the result to an array index (array[ i ] = computation ).


The Formula Node seems to do just fine with working with arrays, but does not have access to the vast amount of built in functions that the MathScript node has. So what I have compromised on is doing all of my heavy computations in the MathScript Node. Then when I get to where I need to do a lot of array indexing, I send over the needed variables from the MathScript Node to a Formula Node to do all of the array work.


I know this isn't the best way to do it and it won't work for all cases of computation, but it works for me. This way, I am able to perform all the math, retain speed, and not have to see all those ugly lines that are present when trying to perform anything but trivial math computations in LabVIEW without a Formula Node or some kind of Script Node.


I'm not sure if that was helpful or not, but I thought I would throw it out there since I just got done fighting with it.

0 Kudos
Message 9 of 9