[R] Issue with gc() on Ubuntu 20.04

[John Logsdon]

On 27-08-2023 21:02, Ivan Krylov wrote:
> On Sun, 27 Aug 2023 19:54:23 +0100
> John Logsdon <j.logsdon using quantex-research.com> wrote:
> 
>> Not so although it did lower the gc() time to 95.84%.
>> 
>> This was on a 16 core Threadripper 1950X box so I was intending to
>> use library parallel but I tried it on my lowly windows box that is
>> years old and got it down to 88.07%.
> 
> Does the Windows box have the same version of R on it?
> 

Yes, they are both 4.3.1

>> The only thing I can think of is that there are quite a lot of cases
>> where a function is generated on the fly as in:
>> 
>> eval(parse(t=paste("dprob <-
>> function(x,l,s){",dist.functions[2,][dist.functions[1,]==distn],"(x,l,s)}",sep="")))
> 
> This isn't very idiomatic. If you need dprob to call the function named
> in dist.functions[2,][dist.functions[1,]==distn], wouldn't it be easier
> for R to assign that function straight to dprob?
> 
> dprob <- get(dist.functions[2,][dist.functions[1,]==distn])
> 
> This way, you avoid the need to parse the code, which is typically not
> the fastest part of a programming language.
> 
> (Generally in R and other programming languages with recursive data
> structures, storing variable names in other variables is not very
> efficient. Why not put functions directly into a list?)
> 

Agreed but this statement and other similar ones are only assigned once 
in an outer loop.

> Rprof() samples the whole call stack. Can you find out which functions
> result in a call to gc()? I haven't experimented with a wide sample of
> R code, but I don't usually encounter gc() as a major entry in my
> Rprof() outputs.

 From the first table, removing all the system functions, it suggests 
that the function do.combx() is mainly guilty.  I have recoded that and 
gc() no longer appears - as it shouldn't with it switched off!  One 
difference was that the new code used the built in combn function while 
the old code used gtools::combinations.  I need gtools::permutations 
elsewhere but that is not time critical.

Thanks Ivan for making me think!

-- 
John Logsdon
Quantex Research Ltd
m:+447717758675/h:+441614454951