Alex Le Dain wrote: Oh dear, the list appears to have died again.
> Just be careful. The penalty of reentrancy is memory. Marking all > your VI's reentrant might give some increased processing speed but as > each instance of the VI has it's own memory space, so depending on > what you're doing making all your VI's reentrant can cripple you with > memory requirements (especially with low RAM systems like FP > controllers). It depends on what you're doing. If you are using the VI in multiple places, the question of whether or not to make it re-entrant is probably dominated by functional requirements- especially if there are uninitialised shift registers storing state information. If you have a sub VI called at only one point in the code, then there doesn't seem to be any loss to making it reentrant; you still only have one copy and you get the speed boost. > I would also think that re-entrancy here is only for testing "as near > to optimum", presumably building a VI into an EXE would achive the > same increase in performance as is achieved with reentrant=TRUE, as > the UI and debug code are removed then. Is that correct Jim? Yes. I've never noticed the speed increase in a built app, but if "remove panel" is allowed to default to true for the subVI then it runs about as fast when built as if it's made reentrant and run in the development environment. -- Dr. Craig Graham, Software Engineer Advanced Analysis and Integration Limited, UK. http://www.aail.co.uk/
