Chart-related subscription history data access and sampling optimization
There are several performance-related problems with the subscription history data sampling implemented in https://gitlab.simantics.org/simantics/platform/-/blob/master/bundles/org.simantics.charts/src/org/simantics/charts/Charts.java#L103-112.
The worst thing is that the amount of excess work grows linearly with the amount of subscriptions defined in the active model and each Charts.createHistorySamplerItem2
invocation will always read all the subscription metadata .txt files from disk, which is terribly expensive compared to caching them.
Caching of course makes the ItemManager
state handling more complex to ensure that up-to-date data for subscriptions is always available. However it is definitely worth it in this case. The simplest way to keep the caches coherent is to invalidate then entirely upon any detection of change (force rebuild). In practice the set of items stored by a HistoryManager doesn't change all that often so cache will hit most often and rebuilds should be few.
Another thing to optimize is the use of ItemManager.search
to find the history items whose variableId
matches the item searched for. Currently it just always loops over all the item Bean
s, reads the variableId
field through Bean
class mechanisms and compares it to the searched for value. If there are hundreds or thousands of items, the time spent in this will linearly grow as well. Again this data is something that hardly changes and can be heavily cached through adding a mechanism to ItemManager
to create an multi-map index (key -> List<Bean>
) of the item beans by a specific field in the beans. This allows the createHistorySamplerItem2
code to just ensure the index by variableId
exists (or create it if it's missing) and directly lookup all the beans whose variableId
matches.
Finally the code will create LevelItem
instances from all the found item beans. This involves reading id
and samplingInterval
fields from the beans. The amount of these beans should always be small so there's not much point in trying to cache even these sorted LevelItem[]
arrays.