Craig Graham [mailto:[EMAIL PROTECTED] wrote: > Rolf Kalbermatter wrote: > > What speeds up things is, that for time critical or subroutine > > priority VIs, LabVIEW not only disables front panel updates (done > > anyway if the panel is > > not open), but even the code necessary to buffer the data for front > > panel display. A bitch to debug such a VI, (you really can't ;-) but > > This can't be all there is to it though. Execution times (ms) for > consecutive tests of a sub-VI; > > 29.6, 29.3 Normal priority, not reentrant, panel open. > 25.9, 26.4 Normal priority, not reentrant, panel closed. > 9.6, 9.6 Normal priority, reentrant, panel closed. > > Going from non-reentrant to reentrant more than doubles the > performance. Simply closing the panel to disable GUI code gives a > comparitively slight improvement. Note that all VIs were saved to > disk before running the tests.
An important remark, a otherwise your timings will be rather off. > Is the data copied to the front panel even if the front panel > is not open, and the update code to copy from the buffers to the > screen is the only thing disabled when a VI is closed? It does > not seem likely, since if you open a subVI after it has executed, > the front panel does not contain the data loaded in to it during > execution. Well that is indeed an indication that it is not copying data on closed front panels but I'm not entirely sure. Removing debugging only however will result in even less performance increase. So it can't be about debugging at all. It maybe has to do about the dataspace preparation then. For non reetrant VIs the data space is shared among all instances and probably needs to be initialized somehow each time the VI is called. Reentrant VIs maintain each their own dataspace and need no additional initialization before each call. Just a guess really! 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]
