I'm trying to log memory consumption spikes in R code, but none of the R profilers can measure the memory consumption of compiled modules. So I've been using top as an alternative, and it works well enough for getting the information I want. The problem is that to catch brief memory spikes, I need to have the delay really low, causing the R process to run substantially slower while top is running. I don't fully understand how top reads the used memory, but is there a way to avoid this slowdown with top or another tool?

My bash script is effectively:

top -b -d 0.1 -p $1 | awk -v OFS="," -v metavar=$2 '@load "time"; $1+0>0 { printf metavar "%.3f,",gettimeofday(); print $10; fflush() }' >> ./other/bench.csv

When I need to benchmark a piece of code, I use R to spawn a new process and execute this script, passing in the PID for R and some extra information that lets me split up the csv file later (it contains multiple related benchmarks). Then, when the code I'm benchmarking is done running, R kills the process where top is running.

EDIT: 10 mins after posting this, I realized I never tried ruling out the other parts of the script (awk and outputting the data to the file) as the culprit of the slowdown. It turns out that if I redirect the output to null or just outright remove the

>> ./other/bench.csv

then the slowdown goes away. So I guess the question now shifts to how do I save this data without the slowdown?

  • You seem to be saying that when your top command writes a lot to disk, and this makes R slow down. This suggests that R is very sensitive to the read/write performance of the disk - quite possibly overloading the disk in brief spikes. Perhaps the memory consumption is a result of (or merely related to) moments where the disk gets overloaded. Is there another disk that R is not dependent on, where you can write the output of your top command?
    – Sotto Voce
    May 26, 2023 at 5:32

1 Answer 1


Inspired by Sotto Voce's comment response to my question (suggesting that R might be sensitive to disk usage), I tried outputting the logging information to a csv file stored using tmpfs (in memory), and the slowdown completely disappeared. This indicates that R is trying to use the file system while I run the benchmark, which I didn't anticipate because none of my code explicitly accesses files. I now suspect one of the libraries I'm using for building my test data is using disk storage behind the scenes to store the data as a way to reduce RAM usage (it's a documented feature for when explicitly loading data from a file, but apparently not so well documented when the data is generated dynamically in code).

So, in short, not an issue with top, awk, or anything else in the bash script. Just unexpected competing disk access.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .