[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange memory problem

Mark D. Williams (markw-xxxnospamxxx@resource-eng.com) wrote:
: "R. Kyle Justice" wrote:
: > 
: > When I do the following:
: > 
: > temp=bytarr(1000,1000,25)
: > temp(*)=10
: > 
: > my computer (a Sparc20 with 128MB of *available* ram) grinds
: > to a halt.  Actually it starts using swap.  Don't tell me
: > PV-Wave is making 5 or 6 copies of the array just to do this
: > simple process!
: > 
: > Has anyone else seen this curious behavior on PV-Wave?  IDL?  I have
: > verified it on a PC, and using different versions of PV-Wave(6.1,7.0).
: > 
: > I have played around with the z-value and 25 (i.e. 25MB) is roughly
: > the cutoff for going into swap for a 128MB system.
: > 
: > Kyle

: I don't have access to a Sparc, but I tried this on PV-WAVE 7.0 on
: both Windows NT 4.0 and RedHat Linux 6.0 on a system with 256 Mb of
: physical RAM and didn't experience any problem: i.e., no swapping,
: returned to the prompt within 3-4 seconds.

: FWIW, if you want to save time and memory, a faster way to do the above
: is as follows:

: WAVE> temp = BYTARR(1000,1000,25, /NoZero) + 10B

Actually I should have given my real problem rather than a
simplified version of it.  Acutally I have two big arrays of
equal size and I am trying to copy one into the other:


I don't want memory fragmentation, that is why I do the process
"in place."  I was told by one person that this left hand operation
generates an array of indices and this is where the memory problem
is coming from.  He suggested the IDL (I am assuming) function
REPLICATE_INPLACE.  Well, I don't have that on PV-Wave(or do I?)
and it really is not helpful for my actually problem (only the
simplified one).  So it appears that I am stuck with fragmentation
or disk swapping.  Choose your poison.

: Note, was it your intent to end up with temp being an INTARR? By
: assigning
: 10 instead of 10B, that is what you're ending up with.

I thought including the * operator on the left side would 
preserve the data type.

: Regards,
: Mark Williams
: Resource Engineering, Inc.

Kyle J.