Closed achimstruve closed 1 year ago
I think this should focus on our data processing because it takes ~7.5 seconds. I think we should keep our normal data processing for testing, but for actual simulation purposes we cut down what we processess to what a user defines they want to see or what we know we are going to put in graphs.
Yes this is a good idea to only postprocess the data that is currently of interest in a specific instance of the web-based visualization.
Once we build the graphs we can create a new optional input for the post processing function to constrain what's processed
Which is basically what kind of result the user wants to see.
I know that others are doing a massive pre-processing where they sweep a big range of parameters in advance so that the user only toggles between already processed data. This would constrain the range of parameters and their discrete steps. Also it could serve as a starting point and once a user wants to be more granular he can then start his own simulations.
For this first MVP version I would just prefer focusing the on-demand live simulation performance though.
Today we found that we want to implement an if-statement to only do the loops over all the agents if we actually use a certain utility. This is one performance improvement that we identified. Whoever is interested can work on this.
Now I implemented additional if-statements before for-loops over agents to only run them if necessary. The performance of the pure model simulation changes now w.r.t. how many utilities are used. Meaning utilities don't require much computational load if they are not used now.
The overall simulation testing stats changed now as follows as consequence of these changes: All utilities enabled (old configuration) Simulation time: 0.80s Simulation + post processing: 41.8s
Using only staking vesting utility Simulation time: 0.52s Simulation + post processing: 39.9s
I am closing this issue now as we found out that the actual performance bottleneck is due to the frontend / UI.
At the current state we focused more on functionality than on performance. In this issue we can discuss different performance related topics.
In general we chose a modular approach for all utilities and policies. This goes at the cost of performance as we incorporate many more for-loops than actually being necessary.
At the current state of the project this is not a big problem as one simulation run requires less than a second to finish. However, for futures optimization procedures it will matter.
Leaving this here for anyone who wants to improve the code base for better performance.