Closed plietar closed 10 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
4970334
) 95.86% compared to head (c9cdee3
) 96.28%. Report is 12 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Thanks. I've added two microbenchmarks, one which does a single render()
call and one which calls it as many times as there are timesteps, mimicking the behaviour of a full simulation.
The
Render$render
method is used throughout a simulation to store data that needs outputting at the end. It does so by creating a vector per metric, large enough to fit all timesteps.Unfortunately, each time the
render
method is called, the assignment into the vector actually creates a new copy, instead of modifying it in-place. For long simulations (ie. tens of thousands of timesteps), these vectors are both fairly large and get copied over and over again at each timestep, to the point where therender
method dominates the execution time.The core of the problem can easily be reproduced by recreating the same conditions of the
Render
class, using a vector stored inside of an environment:Here
e
mirrors theprivate
environment of theRender
class, as it would be constructed by R6. Thetracemem
call is used to trace copies of the vector. Each subsequent assignment to the vector creates a new copy of it, which can be seen as tracemem lines in the console.I did experiment with ways of avoiding the copies without resorting to C++ code, but I couldn't find anything that wasn't made of horrible hacks.
The patch here fixes this issue by creating a C++ class, that acts as a thin wrapper around a vector. Thanks to this indirection, the vector is guarateed to have reference semantics and be modified in-place. A method exists on the wrapper class to extract the underlying vector. This does incur a copy, but is only expected to be called once (per vector), at the end of the simulation.
For large runs, this change has a dramatic effect of the performance of the end-to-end simulation. Using malariasimulation as a benchmark:
The impact is much less noticeable are shorter runs, since the vectors being copied are much smaller (on the order of 20% improvement for a 10'000 time steps run, 5% for 5'000 time steps).