The cache does offer quite an improvement (assuming it works correctly!) for realtime charts in that it allows the client to only query for the most recent data from the gateway, instead of querying the full realtime range each time.
The cache should manage itself, though perhaps it’s allowing itself to grow too large compared to your client’s available memory. It roughly tries to keep itself under 20mb, but perhaps there’s an issue with the bookkeeping in your case.
On one hand, this cache has existed more or less unchanged for 6 years, so there must be something about your particular use case that triggering something we don’t see often. On the other hand, I will say that we just ran a multi-day profiling test specifically because another customer is reporting something very similar. That test showed no memory growth, but something is definitely going on… we just need to figure out what it is.
Since you said you were doing testing, I’ll just through this out there- if you can, and would be willing, to get me access to launch the client remotely, I could run some more advanced profiling on it. If that’s not possible, there are a few other options: we could just turn the logger “Tags.History.Cache” to debug in the client (from Help>Diagnostics) and see if it says anything interesting as it starts to get slow, or you could use a tool like jmap to get a memory dump as it gets slow and then get that to us.
Feel free to PM me if you want to hash this out further.