slow f labview 2011

[Dennis_Knutson]

Can you narrow down where the delay is? Are you sure it's not in the database reads and a result of the move to a new 64 bit OS? Are you using the latest driver from Oracle? Are you using NI's database toolkit?

[instrumento]

The looping over the controls and rows of data is where the time is spent not in the database retrieval.  I've checked that.  I'm using the latest Oracle 64 bit ODBC driver.  I wrote the database functions myself by calling the ADO ActiveX interface.

[majoris]

How much data are we talking about? What does the memory profiler tell you?

[instrumento]

Didn't do that on either of the cases, but one would expect that a machine with 4 GBytes of RAM and a 64 bit virtual address space would handle it a bit better than a machine with 2 GBytes of RAM and a 32 bit virtual address space, which is the only point I'm trying to make here.

[majoris]

Maybe.

Do you know that the VI is even working, or could the upgrade process have introduced some bugs?

Maybe try loading a substantially smaller data set and go from there?

[instrumento]

Yes, it works fine.  We load 7 sets of data from different DB tables.  The first two sets are read in, much slower than before but because they are smaller one can wait for it to complete, and the data looks fine.  The third data set is much larger and the code just keeps spinning.  I've added indicators to the loop variables and can see them inching upward on the probe window.  Last time I gave up when about a third of the data was read and stored in the array, as it was late and I needed to put the old machine back in to run production before I left.  (We have close to $250k of equipment attached to each tester, so there isn't a spare one that I can use all the time to test this.)

[MoReese]

Can you disable part of the DB activity and look at the slower section of code, or slowest?  I don't know how you have it structured or if it's even possible w/o too much trouble (based on your description of it's size).  If you have a service agreement with NI, I would open a case with them as well and see if they can assist you.

[instrumento]

I have a ticket open with NI already. I'm not at work today (posting from my phone} but eventually I'll reduce this to a simple VI I can send them sure

[Jim_K]

Here is a code sample that I put together. The code I put it in to measure elapsed time doesn't seem to work. It takes longer for this code to run that what the elapsed time reports. In any event, I must be misunderstanding the amount of data you have, since my sample execute quickly.

I don't understand why your data has to be visible on the front panel. My sample code seems to execute much more quickly when the indicator is not visible.

[MoReese]

---

@Jim K wrote:

Here is a code sample that I put together. The code I put it in to measure elapsed time doesn't seem to work. It takes longer for this code to run that what the elapsed time reports. In any event, I must be misunderstanding the amount of data you have, since my sample execute quickly.

I don't understand why your data has to be visible on the front panel. My sample code seems to execute much more quickly when the indicator is not visible.

---

Of course it does.  Your screen doesn't have to refresh all the data.  You can place 2D arrays or clusters on the fp and it can work just fine.  But if you have too much data, it can bog down your system.  I have used 2D arrays on the fp before, but it was more as a troubleshooting aid, plus I only use them on a subVI.  Never the top-level VI.