#1

I want to be able to estimate how much memory a pin is taking on RStudio Connect. Below, a link to an image of the before and after when I upgraded from pins 0.4.5 to 1.0.1. I thought that the metadata of the newest version would tell me memory, it does not. And it lacks the preview which surprised me.

comparison screenshot

According to the pins web site, file size is available: screenshot

When I run this code, I don't see file size (I do have a pinned data frame).

How can I go about estimating, or knowing precisely, the memory a pin is taking up? Why doesn't it always show up for all pins? That could be estimating it at the time of creating/updating it, or, querying it after it's created.

#2

Thanks for reporting this!!

When you say "physical memory," do you mean the "size of the pin"? Inside RStudio Connect (if you are a collaborator on the pin), you can see the "bundle size," which gives some sense for size. (You have to look at "Source versions"):

image
image558×504 33.9 KB

However, it looks to me like pin_meta() may be surfacing more information than we do in the UI. Would you mind filing an issue on the pins repo to take a look at this? It sounds to me like a definite improvement that we could take a look at!!

#3

I've seen this screen many times but didn't think about looking there. I do mean size of the pin, specifically, I want to know how close a pin might get to taking up my limited RStudio Connect box memory. 04.09.2022-11.17.33 shows the bundle size and the size of the downloaded data.csv. It's a pretty big gap-- is the bundle going to be close to the pin?

I will make the issue in the repo, it wil be helpful to see it in Connect.

#4

Interesting! I think it's safe to say that the two will be correlated. However, csv is a very inefficient storage mechanism IIRC, and I believe pins uses RDS or some other compression mechanism to simplify things / reduce storage size. In sum, I do not know how the mechanics work, but I do not think they will be exact :sweat_smile:

I definitely agree that it should be helpful to see in Connect! But disambiguating between compression / storage mechanisms may be tricky for this field in particular