W jaki sposób zarządza się pamięcią podczas nadpisywania obiektów R?

Question

Obsługuję niektóre duże zbiory danych i robię co mogę, aby pozostać pod ograniczeniami pamięci R. Pojawiło się jedno pytanie dotyczące nadpisywania obiektów R. Mam duży obiekt data.table (lub dowolnego obiektu R), który musi być wielokrotnie kopiowany do tmp. Pytanie brzmi: czy robi to jakąś różnicę, jeśli usuwam tmp przed nadpisaniem? W kodzie:

for (1:lots_of_times) { 
    v_l_d_t_tmp <- copy(very_large_data_table) # Necessary copy of 7GB data 
               # table on 16GB machine. I can 
               # afford 2 but not 3 copies. 
    ### do stuff to v_l_d_t_tmp and output 
    rm (v_l_d_t_tmp) # The question is whether this rm keeps max memory 
         # usage lower, or if it is equivalent to what an 
         # overwrite will automatically do on the next iteration. 
} 

Załóżmy, że kopia jest konieczne (Gdybym dotrzeć do punktu, gdzie trzeba czytać very_large_data_table z dysku na każdej pętli, zrobię to, ale stoi pytanie: będzie żadnej różnicy na maksymalne użycie pamięci, jeśli jawnie usuwam v_l_d_t_tmp przed ponownym załadowaniem?).

Albo, aby nauczyć człowieka łowienia ryb, co mógłbym napisać (w R, nie wdawać się w ps), aby samemu odpowiedzieć na to pytanie?

To całkowicie OK, jeśli odpowiedź okaże się: "Zaufaj zbieraniu śmieci."

Answer 1

To jest komentarz bardziej niż odpowiedź, ale staje się on zbyt długi.

Domyślam się, że w tym przypadku połączenie z rm może być prawidłowe. Myślę, że począwszy od drugiej iteracji, możesz mieć 3 tabele w pamięci, jeśli nie zadzwonisz pod numer rm. Podczas kopiowania dużego obiektu, R nie może zwolnić pamięci zajmowanej przez v_l_d_t_tmp przed końcem kopii, ponieważ wywołanie funkcji może mieć błąd iw tym przypadku stary obiekt musi zostać zachowany. Rozważmy ten przykład:

x<-1:10 
myfunc<-function(y) {Sys.sleep(3);30} 

Tutaj zdefiniowałem obiekt i funkcję, która zajmuje trochę czasu, aby coś zrobić. Jeśli spróbujesz:

x<-myfunc() 

i przerwać wykonywanie zanim się skończy „naturalnie”, obiekt x nadal istnieje, z jego treścią 1:10. Sądzę więc, że w twoim przypadku, nawet jeśli użyjesz tego samego symbolu, R nie może uwolnić swojej zawartości przed lub podczas kopiowania. Może to zrobić, jeśli usuniesz go przed następującą kopią. Oczywiście obiekt zostanie usunięty po skopiowaniu, ale może zabraknąć w nim pamięci.

Nie jestem ekspertem od wewnętrznych elementów R, więc nie przyjmuj za pewnik tego, co właśnie powiedziałem.

Answer 2

Oto kolejny pomysł ... nie odpowiada bezpośrednio na twoje pytanie, zamiast tego próbuje obejść go, eliminując problem z pamięcią w inny sposób. Może dostać myślisz:

Co jeśli zamiast buforować very_large_data_table, a następnie odczytać je tylko raz, zrobić co trzeba zrobić, a następnie wyjść R. Teraz napisać pętlę poza R i problem z pamięcią znika. To prawda, że ​​to kosztuje więcej procesora, ponieważ musisz czytać w 7 GB wiele razy ... ale może warto oszczędzić na kosztach pamięci. W rzeczywistości zmniejsza to o połowę zużycie pamięci, ponieważ nie trzeba już kopiować tabeli.

Poza tym, jak zauważyłem w komentarzach @konvas, również stwierdziłem, że rm() nawet z gc() nigdy nie dostarczył mi tego, czego potrzebowałem w długiej pętli, pamięć po prostu kumulowałaby się i w końcu ugrzęzła. Wyjście z R jest łatwym wyjściem.

musiałem to robić tak często, że pisałem pakiet mi pomóc przedmiotów cache tak: simpleCache

jeśli jesteś zainteresowany stara, to będzie wyglądać mniej więcej tak:

to zrobić poza R:

for (1:lots_of_times) { 
Rscript my_script.R 
} 

Następnie w R, to zrobić ... my_script.R:

library(simpleCache) 
simpleCache("very_large_data_table", {r code for how 
you make this table }, assignTo="v_l_d_t_tmp") 

### do stuff to v_l_d_t_tmp and output