技术优化labview程序性能英文vi performance

1、Optimizing VI PerformanceDan HedgesOverviewUnderstanding and Locating Performance ProblemsUnderstanding areas in LabVIEW that affect performanceMemory copiesUI redrawsLibrary selectionProperty Node usageThread frictionReentrant VI usageSteps to Improving PerformanceMake your VI workRun the VI Perfor

2、mance ProfilerImprove performance of key areasWhy Should You Profile Your VIs?The 80/20 rule of software performance80% of the execution time is spent in 20% of the codePerformance improvements are most effective in the 20%Guessing which 20% is difficultProfiling DemonstrationSelect ToolsAdvancedPro

3、file VIsCommon Causes of Performance ProblemsIncorrect codingBad algorithmImproper library callsUnnecessary repetitionRecalculating a value rather than storing it for reuse on each iterationIncorrect timingToo earlyToo lateMemory ManagementThe most common and mysterious reason for poor performance o

4、f VIsLabVIEW handles memory management automaticallyYou do not need to code when to allocate or deallocate memoryYou have less control over when memory operations occurExecution DataDiagram data is called execute dataLabVIEW tries to minimize the number of data buffers neededFunctions that just read

5、 the data do not need to copy itThis diagram uses about 4K of data totalExecution Data, ContinuedFunctions that read can be scheduled to run before functions that modifyLabVIEWs scheduling is good, not perfectBuilding Arrays and StringsFunctions that tend to cause memory reallocationBuild ArrayConca

6、tenate StringsBad Use of the Build Array FunctionBetter Use of the Build Array FunctionGood Use of the Build Array FunctionBest Use of the Build Array FunctionType ConversionsMake programming easierExplicit bulletsImplicit dotsRequire extra time and memoryLimit conversions by using consistent data t

7、ypesOnly limit conversions that are executed oftenAvoid Coercion DotsAvoid Coercion Dots Results from profiling the previous two VIs:Slow LibrariesThe easy way is rarely the efficient wayHigher level VIs do many things that may not be requiredDAQ Easy I/O performs reconfiguration on each callFile pr

8、imitivesWrite characters to file will perform many operationsOpen file, Seek file, Write block of characters, Close fileCan be 70 times slower than the write primitive aloneNeither are bad to use until you put them in a tight loopMath EfficiencyLabVIEW compiler generates more efficient code in primi

9、tives than chained operationsMath primitives with an array input are faster than performing the array multiply using a loopIs fasterthan -UI UpdatingDrawing to the screen is the most overlooked performance bottleneckExpensive math or driver calls are more obvious than expensive drawingLike memory ma

10、nagement, LabVIEW tries to optimize UI drawing but it can not perform miraclesUI ThreadFront panel updates occur in the UI threadExecution takes place in other threadsShared data must be protected, so LabVIEW creates an extra copy, called a transfer bufferPanel and Diagram DataFront panel controls a

11、nd indicators need their own copy of the data to display, called “operate data”This VI uses about 8 KB of data if the panel is open, and about 4 KB otherwiseOn multithreaded systems, an additional 4 KB of “transfer data” is usedWhen Do Controls Keep Copies of Data?Controls and indicators keep “opera

12、te data” when the front panel is in memoryThe front panel is kept in memory in the following situations:The front panel is openThe VI has not been savedThe block diagram uses property nodesWhen Do Controls Keep Copies of Data?Local variables read from and write to the operate dataControls and indica

13、tors that have local variable references also keep a copy of their operate dataUI ManagementOnly update indicators as often as you needMore than 10 times per second is excessiveUnderstand indicator data copiesData is copied from the wire to the transfer buffer each time you update the indicatorData

14、is then copied to the indicator on each updateIndicator UpdatingIf an indicator is placed in a loop, you should use a timed loop or throttle the update rateIndicators can be updated at the expiration of a timer after a particular number of iterationsSubVI indicators should not be placed into a loopP

15、roperty Node Effect on PerformanceControl and Indicator Property nodes are slowControl properties require a thread swap to the UI thread to executeProperty Nodes can not run in parallelMany will force UI updates on completion of that nodeProperty NodesChaining together propertiesCause multiple threa

16、d swapsCause multiple UI updatesIt is better to run the VI in the UI thread so it does not have to swap threads on each property nodeProperty nodes in an un-throttled loop are badDefer Panel UpdatesWhen performing multiple control property changes on a graph, use “Defer Panel Updates”Disables UI ref

17、resh until the property changes are completeControl ReferencesThere are performance tradeoffs to using control referencesProperty nodes using control references have the same performance issues as regular property nodesThe value property has the performance characteristics of a Property Node, not a

18、terminalSubVI CallsSubVI calls are relatively expensiveUse subroutine priority if you have determined that a subVI is the hot spot and the subVI is called rapidlyCalling a subVI in a different execution system can be really expensiveHowever, calling a subVI does not inherently cause a new memory cop

19、yInterfacing to External CodeLook for “red” Call Library Nodes or Code Interface NodesRed nodes cause thread-swap every time they execute, yellow do notActive X controlsAutomation servers created via Automation Open can be called without swaps (if the server supports it)Controls always are called with thread swaps Reentrant VIsUsing reentrant VIs in two d