"George Gatling (Contractor)" <[EMAIL PROTECTED]> wrote: >I am pretty surprised to hear so many people clamoring to keep the top >level VI laden with code. In nearly all of the other languages (admittedly >those crude text based ones) the convention is to keep main() or its >equivalent relatively codeless, except to start the necessary objects or >loops. Let me be the first to say the analogy between the top level vi and >main is not wholly accurate, but they are certainly similar. But from some >simple benchmarks, it is apparent that moving indicator updates out of >their "native" diagram is a serious performance hit. This, IMHO, is absurd >and should not be.
You shouldn't compare potatos and oranges. One is dataflow and the other is sequential programming. While dataflow is the main driving force in LabVIEW it is also the point which is optimized and determines the operation of the program. Using reference nodes to update the value, or even globals contradicts dataflow greatly. To maintain a predictability of code execution a lot of protection around these asynchronous operations has to be done, which results always in memory or, and mostly and, execution speed penalties. This is still a lot better than code which starts to behave completely unpredictable and often even wrong as a buffer could change its value halfway while another function reads its content. >Now, performance aside, why is it so critical to have all of the panel >update contained in one potentially mammoth vi? It is no big deal if there >are only a few indicators. But when you start really piling them on, >managing them becomes a pretty big deal. Now it might not be such a hot >idea to scatter front panel writes throughout the application, but I don't >think it is a great idea to confine them only to their diagram either, >especially when that diagram is the top level. Well having all sorts of updates from (in LabVIEW very easily parallel) tasks is basically the best way into debugging hell. Another issue is the question if a user interface should be so complex as to contain 100 controls for user configurable parameters as well as another 50 process variable displays. Personally I think not and prefer to separate parameter configuration and process display in mostly independant screens. If you apply that principle you hardly ever get a single mammoth VI, but rather several independant, small, and managable user interface VIs. Also the way I do it is usually to keep the update and user event handling in the main GUI VI but put all the process and calculation intelligence into several smart manager subVIs very often built around a LabVIEW 2 style global buffer. Their actual values are returned by dataflow through the connector and effectively updated in the main diagram of the GUI, giving the maximum performance. >So it would seem like the idea of globally available references to the top >level indicators is probably NOT good programming practice, but I am still >latched on to the idea of moving the updates into their own sub-hierarchy >and out of the top level. This will incur the by reference performance >hit, but for now that is not a big deal for me as I only need about 0.5 >updates/sec. And when the time comes that I need better performance I >expect NI will have sped up the reference operations ;) Maybe. It will mean a lot of extra infrastructure to decouple the property node from the actual control and protect the different user and program actions from interfering wih each other. It might be happening sooner or later, but I don't think you will ever see the same performance for references as for direct terminal updates. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
