haacked
commented
6 years ago The InMemoryResultProvider is primarily for demonstration purposes. It lets you try out the library to see how it works, but isn't really meant for production use. Perhaps we could make that clearer. InMemoryResultProvider has no way of knowing when the experiment is over and you no longer need the results. That's why it holds onto results. If you use it in production, you need to clear the results on occasion.
For production use, the recommended approach is to implement IResultPublisher to publish results to a data store that allows you to query and analyze results. For example, you might publish results to a SQL database, Data Dog, etc. Then you can create nice dashboards for your code experiments.
I'm using scientist within a scheduled task that runs every hour to test a new approach of fetching data from a database. What I noticed is ever since I've added scientist.net in the solution, the memory consumption of the app goes up with every run.
Scientist is comparing 2 lists of around 100k items.
After some investigation and debugging I noticed that InMemoryResultProvider will always keep a copy of the last result which in turn will have a copy of the original array. Clearing that up fixes the memory issue, however don't understand the reasons why this (and a lot more stuff in the whole library) is static.