Some metric providers may interact with components that have a variety of metric types. Some of these metrics may be static, others may update once every minute, even more may be expected to update every tick. The current design treats all metrics the same, updating every metric during every cycle.
If an input adapter tightly integrates with its components (such as the Mekanism input adapters), it is fair to say there would be established knowledge on which metrics update "fast" and "slow".
The Backplane could be configured to support several cycle speeds, prioritizing certain inputs to be read more often than others in the same period of time. Input adapters themselves could define their APIs in such a way to divide the metrics into groups, like "fast", "slow", and "static". These groups would have default cycle times, but could be overridden by a user.
However, this introduces a challenge with how the Output Adapters should behave. Some output adapters may not benefit from accelerated update times, or cause confusing/corrupted results. Other outputs would greatly benefit, such as charts and other visual indicators.
This issue will serve as a place to record ideas during the planning of this feature.
Some metric providers may interact with components that have a variety of metric types. Some of these metrics may be static, others may update once every minute, even more may be expected to update every tick. The current design treats all metrics the same, updating every metric during every cycle.
If an input adapter tightly integrates with its components (such as the Mekanism input adapters), it is fair to say there would be established knowledge on which metrics update "fast" and "slow".
The Backplane could be configured to support several cycle speeds, prioritizing certain inputs to be read more often than others in the same period of time. Input adapters themselves could define their APIs in such a way to divide the metrics into groups, like "fast", "slow", and "static". These groups would have default cycle times, but could be overridden by a user.
However, this introduces a challenge with how the Output Adapters should behave. Some output adapters may not benefit from accelerated update times, or cause confusing/corrupted results. Other outputs would greatly benefit, such as charts and other visual indicators.
This issue will serve as a place to record ideas during the planning of this feature.