Performance Arrays in Classes

[DAckermann]

Hello Forum

I ran into a performance problem with arrays in class objects in LVOOP.

Basically I have an IO system that generates data as a big 2d byte array. This data is chopped in smaller 2d arrays and written to the objects to which the data belongs.

I noticed now, that with a 100 objects just the data separation (no processing at all) already takes around 20 ms on my machine (Laptop i7 Win7 64 bit). I need to reduce this drastically. Unfortunately I am running out of ideas. I tried to use a DVR to 2d array in the class, but this did not really boost the performance.

I hope I am just missing something and somebody can bring some light in how to make this workable with LVOOP.

I attached a little project, that basically shows the problem.

Help is highly appreciated 🙂

Greetings

[Stephan_D]

Hello,

this is a tough question. I used your test VI and it takes ~13ms on my machine (Win 7 64-Bit, 8GB Ram, Core i7).

I don't know if its possible to reduce this time drastically. It could maybe improve the performace if you try to use another datatype lika a 1D array or maybe an

[DAckermann]

Hi

I played around with putting the data chopping in a C++ Dll and reduced the time to 7 ms. When I don't carry the data arrays around in the class objects and leave it in the C Dll, it seems I can go down to 2 ms.

So my plan is now to build a vector of objects in the C++ Dll that carry the data arrays. The LabVIEW objects can access their data through a dll function.

It's more work, but I can't go back from developping in LVOOP anymore..

It would be just tooo great to have real pointers in LabVIEW..

Cheers

[Jacobson-ni]

DA,

I benchmarked your VI at around 13ms without making any changes to your original program.  Without really looking into what you were doing I allowed for parallelism in your for loop and by using the default setting of 4 parallel instances got it down to ~5ms (it seemed to fluctuate between 4 and 6ms).

There might be other things you can do but if you can get away with allowing for parallelism that usually speeds things up a lot.

[DAckermann]

Oh yes. That is a good hint. Somehow forgott about that..

[DAckermann]

I just noticed, why parallelization did not came to mind. It has to work with LV2010..

[smithd]

The code generated for a parallel for loop is actually pretty simple. Divide the autoindexing arrays by N (ie the array of objects), split the array, and make N copies of the loop in parallel, indexing off of the split array, then rejoin the results. Since the giant 2d array is read only you don't need to worry about splitting that one. Its not as nice as right clicking on the for loop and asking it to parallelize itself, but...

I'm guessing most of the execution time is coming from copying info out of that 2D array so yeah, I don't see a way for labview to beat pointers except by going parallel.

What is the performance goal? Ie why is 20 ms too slow?

[DAckermann]

I solved my performance problems by putting the data arrays in a c++ dll. Now I am running with 2 ms, which is fine for me.

The code is going to be part of a driver library. So I don't really know on what systems it will be run and how the parallelizing effect would be on different systems.The C++ dll seemed savest to me.

[Yamaeda]

Since you have an array of objects you can autoindex the loop and parallellize it. 

I think the Get Subarray takes alot of time, not the writing to the object, do you include that when you compare to the DLL option?

/Y

[DAckermann]

Yes, I identified the get 2d subarray function as performance killer.

Now I write the 2d process data array to a memory in the dll once. In the dll I also have a array (vector) of objects with own memory for the process data. The for-loop for data chopping from the 2d process data array to the objects data is done in the dll by memcopy.

Much faster..