Lots of Programs vs mostly in Main

[davidbgtx]

Does it increase scan time to have a LOT of programs vs putting most everything in the MAIN?

[BobO]

Does it increase scan time to have a LOT of programs vs putting most everything in the MAIN?

If a good percentage are not running, it can improve it. There is some overhead though, although I'm not even sure what it is. Think I'll check that.

[Controls Guy]

I wanted to see the impact the other day of some programs that run quite a few scans on a particular event, and I wanted to tune how yieldy I configured the programs to be.  I popped up a trend view with the scan time and some discretes to time stamp the trend with the event.  (I had previously been going off max scan time in system info, assuming that was the impact of these programs, but must have been something else, because these programs only increased scan time about 60% from the base level).  Sweet tool!     This thing programs itself!

[BobO]

$MaxScanTime bumps up a bunch...but it is somewhat Heisenberg-y and not a real indication of performance. Ethernet comms are kinda ugly due to the stack overhead, and monitoring causes lots of comms. Serial/USB comms cause far less impact...no stack.

$ScanTime (DST1) is actually an exponential moving average, and is a much better indication of overall performance. If you need the actual scan time of the last scan, it is in $ElapsedTicks (DST4).

I have never really seen a case when using programs hurts things bad enough to matter, and certainly never enough to give up the benefits of modularity. When you then add YIELD and/or Stages to the mix, it becomes even less of an issue.

[Controls Guy]

$ScanTime (DST1) is actually an exponential moving average, and is a much better indication of overall performance. If you need the actual scan time of the last scan, it is in $ElapsedTicks (DST4).

Thought there must be some averaging in there.  There is a long program that runs on the leading edge of an event and another slightly less lengthy on the trailing edge.  Knowing what they do, I'd have expected a square step up, then maybe back down a little (first-scan overhead tasks plus execution of the first loop till yield), then steady till done (one loop between each yield), then back down to the base level.  What I saw with both programs was a linear ramp up to the max, then back down in a concave-up curve ending tangential to the original base number.

[davidbgtx]

I have never really seen a case when using programs hurts things bad enough to matter, and certainly never enough to give up the benefits of modularity. When you then add YIELD and/or Stages to the mix, it becomes even less of an issue.

That's what I wanted to hear, wanted to keep it modular. Thanks

[plcnut]

In Bobo's words: I "embraced program blocks" in my first DoMore project. It has very little in MAIN, with... ahem... a *few* program blocks.
It gets a lot of work done while maintaining impressive scan times.