Closed kylebaron closed 4 months ago
Do you know of any way to profile this branch (
refactor/deque
) against, say,refactor/alag-insert
to understand the impact?
I think we can use Valgrind's Massif heap profiler.
Here's your script from above, removing the timing statements and output comments.
And then on the tip of this PR (864a432f), I did
$ make
$ R -d "valgrind --tool=massif --massif-out-file=massif.out.pr" -s -e 'source("do.R")'
(If on Metworx, you'll need to install valgrind: sudo apt-get install valgrind
.)
And similar for the tip of refactor/alag-insert
(573e9c70):
# check out refactor/alag-insert
$ make
$ R -d "valgrind --tool=massif --massif-out-file=massif.out.base" -s -e 'source("do.R")'
Here are some exported massif-visualizer
plots (need to install on Metworx).
refactor/alag-insert
this PR
Anyway, I'm not sure how useful those particular images are (also visualizer UI is more helpful than static image) or whether that script is a good thing to profile, but let me know if you think that's looking like the sort of info you want and we can explore more.
Thanks a lot, @kyleam . This is super cool. I was able to run with valgrind on Metworx with a reduced script (just the very last problem ... with larger data set). I installed the visualizer, but wasn't sure how / if I could invoke this from the comand line.
Anyway, this seems to say that the allocations are pretty close between the vector and the deque? Maybe a small difference but it didn't increase by 50 or 100% or anything like that. Is that the way you're viewing this?
I installed the visualizer, but wasn't sure how / if I could invoke this from the comand line.
Ah, sorry, I meant to mention that. I'm sure you could set up some port forwarding or whatnot to see it via laptop, but I just invoked it from the command line (make sure DISPLAY=:99
is set in environment) and then went to the remote desktop available in the Metworx interface.
Maybe a small difference but it didn't increase by 50 or 100% or anything like that. Is that the way you're viewing this?
Yes, that was my initial take.
If the code compiles, the behavior with deque should be identical to what we got with vector. The real test is performance with lag times or other times we need to insert records into the stack.
reclist
is a collection of records for an individualrecstack
is a collection ofreclist
comprising a population;recstack
never needs to be sorted or resized@kyleam - I'm pretty sure this is the right thing to do. Changing to
deque
has done a pretty good job addressing the problem I wanted to solve. One thing I've read aboutdeque
is that it uses more memory, but I don't have a good feel about how much more or if this is even a factor here. Do you know of any way to profile this branch (refactor/deque
) against, say,refactor/alag-insert
to understand the impact?Benchmarks
deque
After conversion to the deque
After controlled insert
Original (currently in main branch)