A few more thoughts: 1) Shane has definitely hit on the right idea, but there is another dimension to it. Using complex data structures does add additional memory and performance hits beyond the fact that you have to keep all of the data together. When storing data in memory there is obviously some overhead associated with each level of complexity you add to a data structure (you have to somehow keep track of what is in the structure, and where it resides in memory).
Does this mean that you shouldn't use complex data structures? No, the value in readibility and maintainability that you gain by using well designed data structures will almost always outweigh the modest performance hit they cause. There are almost always optomization issues involved with writing better code (true of any language), if memory and speed are truly all you are concerned about, then you would be writing in assembler. As Shane said, the memory and performance guidelines are generally only applicable in cases of mis-use, or in cases where you have to squeeze just a few microseconds out of a VI. 2) You should never use a local variable to pass data that could be passed by a wire. Local variables cost memory and performance (not much, you shouldn't worry about it in cases where they are neccessary, but it can add up if misused). In addition, they reduce the readability of your VI, since there is data being transfered without any visible link. They also make execution control harder and can lead to race conditions if misused. As Shane said, if you find that you have to string wires a long way across your diagram then you probably aren't making use of SubVIs or organizing your block diagrams well. 3. There are some Object Oriented principles which are difficult to accomplish with LabVIEW. It's generally possible to do most things, but they may be more difficult than in other languages (which in some cases may be for the best, design patterns which apply well in other languages don't always make as much sense in LabVIEW). LabVIEW is a language which is under constant development, and it is likely that Object Oriented programming will become easier with time. In the mean time, I believe that there have been a couple of open source projects aimed at improving LabVIEW's Object Oriented capabilities. I haven't personally used any of them, but if you are interested I would guess that openg.org would probably be a good place to start. 4) NI teaches a number of courses aimed at improving development techniques (LV Intermediate I probably focuses on it the most). Ideally, taking these would be a great idea, however, we understand that this may not be affordable or practical for university students. The ideal solution on an academic level would be to teach university courses on it, or at least include it in current courses. NI is very commited to assisting anyone who wants to expand the LabVIEW instruction which their courses are providing, we provide a large body of resources and contacts which can make it a lot easier to incorporate this material. You should encourage your professors to work with their local NI reps to take advantage of these resources. For a more short term solution, the LabVIEW Development Guidelines would probably be a good place to start: http://digital.ni.com/manuals.nsf/webAdvsearch/5FBA64AD223A76A786256D2C00561F2D?OpenDocument&vid=niwc&node=132100_US 5) As with the rest of your questions, no simple yes/no answer to this one. LV 7.0 is faster for some things, as we are always working to optomize our code and slower for others, as new features or better written code sometimes add overhead. http://zone.ni.com/devzone/conceptd.nsf/webmain/DC9B6DD177D91D6286256C9400733D7F?opendocument provides some examples, but the fact is that it really varies by application. In general they tend to balance out and most applications run at about the same speed. Finally, a note about using the forum: In general, you'll probably get many more answers to your questions if you post them seperately, most people are more willing to read a paragraph or two and post their thoughts on it than they are to read a page and write a long response to a number of questions (luckily there are some exceptions :)). Hope some of that helps, Ryan K. NI
