The update cycle type is a main driver of cpu usage.  Previous checkins have provided the instrumentation to prove that with 'hard coded' longer update times. This checkin removed hardcoding of update times in controllers and allows user control over these update times:
-The ConfigControllers dialog now allows user setting of update interval for each controller.
-New controllers default to a new SystemConfig DefaultUpdateInterval (manual edit of xml file required to change it).
-The PetitionForUpdate threshold (called by each controller thread) is now calculated dynamically from the fastest controller update time.

For easy reference here is a summary of previous checkins:
-VixenPreviewModuleInstance:  add Instrumentation... why is this on own thread?
-ContextBase:  expose lastUpdateMs timestamp
-MillisecondValue: new Instrumentation type
-Element:  more direct collecting of states from contexts (save 30% on Element Update cycle);  ClearStates not used.
-ContextManager:  better instrumentation, ForAll?
-ElementManager: (lock)  better instrumentation, ForAll?,  ClearStates not used.
-FilterManager: (lock) better instrumentation, ForAll?
-HardwareUpdateThread:  instrumentation, scheduling
-IntervalUpdateSignaller:  instrumentation, sheduling
-OutputController:  Record/Playback hooks, no real change
-Recording:  Record/Playback mule
-sln: add new files
-Other output controllers: don't override UpdateInterval