Re: Memory allocation

Anandhi Aavudai wrote:
> Hi NCL users,
>
> I am repeating my earlier query from "ncl-talk Digest, Vol 71, Issue 36" again as I am not sure the reason for not getting any response.
>
>
> I have a script which reads about 195 .nc files one at a time in a do loop. Then each file is regridded and a section is written into a ascii file using 2 other do loops. To my knowledge all the memory allocated for each file in reading, regridding & writing to ascii file is released by using delete statements.

There is an important loophole in that assumption. Because of
fundamental architecture of NCL, individual *strings* that you
create are *never* deallocated until the program ends.

This seems to be true even when you explicitly delete a string
variable. My understanding is that the variable name and some kind
of memory pointer are deallocated, but the actual *contents* of the
string remain permanently allocated behind an untouchable hash table.

Since you are creating strings within loops for lots of of data, you
are accumulating large amounts of unreleased memory and string
management overhead time.

Here is a previous discussion from NCL support, starting at "...NCL
permanently...stores every unique string..."

   http://www.ncl.ucar.edu/Support/talk_archives/2007/0587.html

I think that a method to get around permanent string allocation
would be very helpful for applications like yours. Meanwhile,
please consider the alternatives suggested by Wei Huang and Dennis Shea.

Dave Allured
CU/CIRES Climate Diagnostics Center (CDC)
http://cires.colorado.edu/science/centers/cdc/
NOAA/ESRL/PSD, Climate Analysis Branch (CAB)
*** http://www.esrl.noaa.gov/psd/psd1/ ***

*** NOTICE: NEW PSD1/CAB WEBSITE ADDRESS AS OF 2009-OCT-14 ***
*** PRODUCT AND DATA CONSUMERS PLEASE TAKE NOTE ***
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Thu, 15 Oct 2009 13:17:03 -0600