Hi Seth,
Thank you for the suggestion. Because of using .Call (which does not copy
the value) for both parts of my program, there is no extra copy shown by
tracemem(). Anyway, the information shown by gc() is very misleading as
stated by Prof. Ripley, especially after creating and removing a
c
Hi Yongchao,
Yongchao Ge <[EMAIL PROTECTED]> writes:
> Why am I storing a large dataset in the R? My program consist of two
> parts. The first part is to get the intermediate results, the computation
> of which takes a lot of time. The second part contains many
> different functions to manipula
Dear Prof. Ripley
I am using 32bit Ubuntu 7.04 on Dual Core Intel Xeon Processor 5140. I do
not think that it is the OS's problem in recognizing the memory released by
free(), as the Calloc() and Free() pair works perfectly well in my
C program. I'm assuming that the free() in your post does no
Please do not post to multiple lists! I've removed R-help.
You have not told us your OS ('linux', perhaps but what CPU), nor how you
know 'the memory was still not reclaimed back to the operating system'.
But that is how many OSes work: their malloc maintains a pool of memory
pages, and free()
Hi,
I am not sure if this is a bug and I apologize if it is something I
didn't read carefully in the R extension manual. My initial search on the
R help and R devel list archive didn't find useful information.
I am using .Call (as written in the R extension manual) for the C code
and have foun
