On 15/06/2020 12:30 p.m., Daniel Kelley wrote:
Duncan, thanks very much for that very helpful hint. I got as follows.
My guess is that the first column in rdx$variables is an address
offset, and so it seems that the lion's share of the storage is
dedicated to items with names starting with a decimal point. For
example, the "[[" item is at offset of nearly 4M. I may try fiddling
with my code in which I specialize that method, to see whether I can
reduce the memory footprint. From what I can gather, both linux and
windows build argoFloats into a package with R directory of about 2.5M
size, which is a lot better than what I get in macOS but still over the
warning threshold (I think) and therefore I worry about CRAN acceptance.
The second column is the size, so actually the lion's share is dedicated
to things that are not being shown. They are indexed in the
rdx$references list, and are probably going to be harder to track down,
because they probably don't have names assigned by you.
For example, in the rgl package, I see
> rdx$references
$`env::1`
[1] 661 1037
$`env::10`
[1] 123952 221
$`env::11`
[1] 126378 224
$`env::12`
[1] 128575 226
[ many more deleted ]
Presumably `env::1` is an environment which might be referenced by
several of the functions, and I'm guessing that one of yours is really
big. This can happen accidentally: you have a temporary local variable
in a function and create and save another function, or a formula, or
some other environment-using object, and save the useless local variable
along with it.
I don't have a good suggestion for figuring out what's in the bad
environment; maybe someone else can suggest how to read an object from
the .rdb file using R code. Internally R uses C code for this.
Duncan Murdoch
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
