comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: The best way to keep data in RAM / object-oriented programming
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: The best way to keep data in RAM / object-oriented programming [message #68782 is a reply to message #68781] Thu, 03 December 2009 11:27 Go to previous messageGo to previous message
penteado is currently offline  penteado
Messages: 866
Registered: February 2018
Senior Member
Administrator
On Dec 3, 4:31 pm, nata <bernat.puigdomen...@gmail.com> wrote:
> I'm sorry guys but I don't see the difference.
> I understand what are you explaining and the functionality of the
> NO_COPY KEYWORD but the result is the same...
>
> If I've to store an array fltarr(400,400,24,97) in a pointer, the
> result, in heap memory usage, is the same if I do:
>
> a=fltarr(400,400,24,97)
> b=ptr_new(a)
> a=0l
> help, /heap
>
> or
>
> a=fltarr(400,400,24,97)
> b=ptr_new(a,/no_copy)
> help, /heap
>
> I´ll learn about COMMONs
> Cheers,
> nata
>
> So, that's not what I'm looking for. I need to keep the arrays in
> memory but using less memory resources. Is it possible?

The difference is that in the first way you had, for a while (between
b=ptr_new(a) and a=0l), two copies of the same large array in memory,
one in a, and another in *b. Yes, you free (nearly all) the memory
used by a with a=0l, but before that you wasted all the memory and
time to make a copy of a. Which is particularly relevant if the extra
memory use means having to use disk cache. So use no_copy instead.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: ASSOC vs SHMMAP vs POINT_LUNs vs READ_BINARY?
Next Topic: Re: ASSOC vs SHMMAP vs POINT_LUNs vs READ_BINARY?

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun Oct 12 05:09:06 PDT 2025

Total time taken to generate the page: 0.24179 seconds