Allright, I just spent the last hour chasing this.
Here's a report. My program "Viewer" opens a single datafile (hybrid: part datalog, bart bytestream) produced by another portion (not under test here), and produces a "cache" (the user chooses to put the cache into memory for speed, or on disk for efficiency), calculates other channels (based on flow rates, and emissions readings), and stores them as well.
Then it plots two channels.
Other parts of the program calculate statistics, print graphs, make spreadsheets, make reports, extract configuration stuff, other miscellaneous stuff, but that's not tested here.
Remember that these tests are AFTER I modified the one big problem VI to put the terminal with the large default value INDISE the case that used it, and added locals to all the other cases that used it.
Your questions:
Does the memory usage vary significantly between the 8.2 version and the 7.0 version? (you can use task manager)
The following is the TOTAL COMMIT CHARGE number (from Task Manager) after each indicated step:
| After: | LV 7.0 | LV 8.2 |
| Rebooting | 147060 | 140960 |
| Loading LabVIEW | 162540 | 172580 |
| Loading "Viewer" | 183840 | 202032 |
| Running (short file) | 186020 | 207904 |
| Loading large file | 454916 | 496448 |
| Quitting Viewer | 368848 | 400044 |
| Closing Viewer | 177052 | 186360 |
| Quitting LabVIEW | 143968 | 132568 |
---- I don't see anything terribly unexpected there, although 8.2 is more hungry across the board.
Can you use Profile Performance and Memory Window to narrow down which specific VI(s) (if any) are taking longer to execute and/or using more memory?
I did that and saved two reports, but I can't see anything outstanding. Some are better in 8.2, some are worse.
Have you had the opportunity to run this on a *true* Windows box (not a Virtual PC)? I'm not sure how this impacts performance, as we have not tested it...
I have run 7.0 on a true Windows box. Performance is considerably better.
The virtual PC gets 16575 / 5908 mSec, the real box gets 2500/ 4000 mSec. But that is not the point.
I have not put 8.2 on my real box for fear of contamination issues.
You mentioned that you mass-compiled the VI -- did you cover all the subVIs? I realize this may seem obvious , but I have to check -- when you open up a subVI in 8.2, it doesn't have the asterisk, does it?
No, it does not. I did a SAVE ALL after loading the main the first time. It is definitely saved as 8.2 compiled code.
As a last resort, there are two LabVIEW.ini tokens you can use to turn off constant folding. I do not recommend this procedure for every application, as there could be a significant performance hit. Also, if you upgrade LabVIEW in the future, I would try your application without using these:
Understood. But the "performance hit" you speak of, would be relative to LV 8.2 AS OPTIMIZED by these options, right? In other words, it's not likely to be WORSE than 7.0, is it?
I just tried those two settings. It did NOT affect the overall timing, but it was not recompiled, either.
When I changed my problem code back to the old way (terminal OUTSIDE of the CASE where it was used), I DID NOT get the MEMORY FULL error. The timing was worse, but perhaps having windows open was the cause of that. Perhspa recompiling the whole thing will yield different results.
I will have to try that tomorrow, as I am exhausted right now.
Also, in your e-mail message, you wrote:
omething that I left out was your mention of the FFT example. Does this VI
resemble your problematic application in any way?
No, it doesn't, and that was the point. I have a timing template VI that I use, and I just stuck an 8k FFT in there to test a compute-intensive procedure to see if it showed the same symptoms. It would have been REALLY bad news if it had, but it didn't.
, but I have to check -- when you open up a subVI in 8.2, it doesn't have the asterisk, does it?
