> Hi, thanks for all the good advices. I can't preallocate the array > because I don't know how many items will be in the array. It's based > on what the user input, base on how many temperature and voltages they > want to run the test over. I pull up task manager and the CPU usage > when I ran 1/3 of the input file and it is 100% most of the time, > memory usage is 270096K, physical memory is 129252 K and I have 16340K > left. Is there a way that I can dump this data to a temporary text > file, to a physical memory, then read it back in the end? In visual > basics, Java, and C, there is a routine that you can write to the hard > drive, and then read it back in the end. Is there something like that > in LabView? I have looked at my code and it's as most efficient as I > can make it. If you run the VI server to call subVI A, and if there > are some subVI's in subVI A that you don't use, is it a better idea to > remove the subVI's inside of subVI A. The reason that I am asking > this is because I don't want to remove the excel and html subVI inside > of subVI A, just in case the user want to just run subVI A directly by > itself, and not go through the main VI interface. Thanks again.
I'm jumping in late here, but you have been getting good advice as far as I can tell. RAM and disk is pretty cheap compared to our salaries and time. If your app is correct on smaller data, but slow and unreliable on larger datasets, more memory and disk will probably get you finished, this time. There are limits to the amount of virtual memory that the OS will let an application have, and when you hit that limit, you will definitely have to start processing in blocks or avoiding fragmentation or both. But this takes more code, is harder to debug, and runs slower since the OSes virtual memory algorithms are pretty darn efficient. So unless there are no computer stores or slots available in your computer, this is the direction I'd go. As for preallocating the array, we don't mean in a constant, but before the acquisition loop, if you have the numbers from the user and know how many points will be acquired, you can initialize the array once to avoid fragmentation and help with efficient memory usage. If you don't know for sure, you can preallocate thousands of elements in advance, and at any time in the loop use append or initialize to add thousands more. In this way you again more efficiently grow the array leaving behind less fragmentation. As for the application being as efficient as you can make it, well that is the point of letting others help you. They may be able to make it more efficient still since there are literally hundreds of ways to write these apps because LV is a language and just as there are many ways to describe the problem and solution, some are better than others. As for saving intermediate values to file, you might want to look at the File I/O palette -- it has the blue disk on it. It has all the file I/O access you will need to write data out permanently or temporarily. Also, just posting a bitmap of your diagram will let others see what you see so that your descriptions and theirs will make more sense. Better still, if you can isolate some of your code from the I/O, you can post the VIs for others to flip through and possibly even modify. Greg McKaskle
