CODEWITHSUNDEEP
rfunctionmemorypackage
DeltaIV
DeltaIV

Reputation: 5646

If I call a function which loads an already loaded package, do I occupy twice as much memory?

Suppose I have

library(purrr)

big_data <- replicate(10, data.frame(rep(NA, 1e6), sample(c(1:8, NA), 1e6, T), 
                                     sample(250, 1e6, T)), simplify = F)
bd <- do.call(data.frame, big_data)
names(bd) <- paste0('X', seq_len(30))

source("find_missing_columns.r")

index <- find_missing_columns(bd)

where the content of find_missing_columns.r is

find_missing_columns <- function(dataframe){
  # find columns which are all NA in dataframe: returns a logical vector index
  library(purrr)

  all_na <- function(x) {all(is.na(x))}
  index <-  map_lgl(dataframe, ~ all(is.na(.)))

}

purrr is loaded twice, both in the main and in the function. Does this mean that, while running the function, twice as much memory is allocated for the same package? If this is the case, then packages should not be loaded in functions which I reuse across multiple programs. In other words, I should comment library(purr) in find_missing_columns.r. However, this introduces an dangerous dependency: the called function will only work if purrr has been loaded by the caller. So, should I always use the purrr::map_lgl syntax inside a callable function, in order to both avoid unnecessary memory occupation and not introduce dependencies on the calling code?

Upvotes: 2

Views: 348

Answers (1)

MrFlick
MrFlick

Reputation: 206243

A library() call adds the package to your search path which is session specific and not scope specific. You cannot privately load packages in a function. You can't load the same package more than once. Nothing happens if you call library() again with the same package name.

Generally putting library() inside a function call is not good form. Using the fully qualified name is better. Or if you need to test if a library is present you can use require(). Usually one would just have the library() once at the top of your code.

If you have a bunch of functions that you are sourcing from somewhere, you might want to think about making them a package instead so you can make the dependency on other packages more explicit.

Upvotes: 1

Related Questions