| Re: IDL Shapefile Object [message #28280] |
Fri, 30 November 2001 11:52  |
Kelly Dean
Messages: 92
Registered: March 1997
|
Member |
|
|
Thanks gentlemen,
Using the undocumented feature "HEAP_FREE, pEnts" solved my problem.
Kelly
Kelly Dean wrote:
> I created a little procedure to plot Shapefiles with IDLffShape.
> However, it has a memory leak. Can someone point out a plug to stop my
> memory leak?
>
> The routine works great, but when I have to add graphics to 800 images,
> I run out of memory at around 500 images.
>
> A sample routine is available at ...
>
> ftp://ftp.cira.colostate.edu/Dean/teststate.pro
>
> Kelly Dean
> CSU/CIRA
|
|
|
|
|
|
|
|
|
|
|
|
| Re: IDL Shapefile Object [message #28297 is a reply to message #28296] |
Thu, 29 November 2001 14:31  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
I wrote a few minutes ago:
> The problem here is that the shapefile object returns
> a structure that itself has pointers in it. (This is really
> the only way it can be done, because the object doesn't
> really know anything about the actual shapefile you will
> load.)
>
> When this happens, you are responsible for cleaning
> those pointers up yourself.
It has been pointed out to me that there is
a new routine in IDL 5.5 called HEAP_FREE that
is to be used for exactly this purpose. (I think
I overlooked it because it's not in the IDL 5.5 on-line
help, obviously, since the help is in... Oh, never mind.
I have probably beat that horse enough, although I still
think it is an ass-backwards way to release software.)
Anyway, despite the documentation that is meant to
frighten you away from using it (ala Heap_GC), it
is designed to help you clean up in those situations
where you don't know what it is you have been handed.
It will release (clean-up) all the heap variables
referenced by the argument to HEAP_FREE. So, in Kelly's
case, he could have cleaned up by doing something like
this:
pEnts = PTR_NEW(/ALLOCATE_HEAP)
*pEnts = oShapefile->GetEntity(/ALL, /ATTRIBUTES)
;
FOR I = N_ELEMENTS(*pEnts)-1, 0, -1 DO BEGIN
PlotEnt, (*pEnts)[I], color=color
ENDFOR
HEAP_FREE, pEnts
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDL Shapefile Object [message #28298 is a reply to message #28297] |
Thu, 29 November 2001 13:26 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Kelly Dean (krdean@lamar.colostate.edu) writes:
> I created a little procedure to plot Shapefiles with IDLffShape.
> However, it has a memory leak. Can someone point out a plug to stop my
> memory leak?
>
> The routine works great, but when I have to add graphics to 800 images,
> I run out of memory at around 500 images.
>
> A sample routine is available at ...
>
> ftp://ftp.cira.colostate.edu/Dean/teststate.pro
The problem here is that the shapefile object returns
a structure that itself has pointers in it. (This is really
the only way it can be done, because the object doesn't
really know anything about the actual shapefile you will
load.)
When this happens, you are responsible for cleaning
those pointers up yourself. Your particular test program
can clean itself up by changing these lines in the DrawSHPMap
module:
pEnts = PTR_NEW(/ALLOCATE_HEAP)
*pEnts = oShapefile->GetEntity(/ALL, /ATTRIBUTES)
;
FOR I = N_ELEMENTS(*pEnts)-1, 0, -1 DO BEGIN
PlotEnt, (*pEnts)[I], color=color
ENDFOR
To this:
pEnts = PTR_NEW(/ALLOCATE_HEAP)
*pEnts = oShapefile->GetEntity(/ALL, /ATTRIBUTES)
;
FOR I = N_ELEMENTS(*pEnts)-1, 0, -1 DO BEGIN
PlotEnt, (*pEnts)[I], color=color
Ptr_Free, ((*pEnts)[I]).vertices
Ptr_Free, ((*pEnts)[I]).measure
Ptr_Free, ((*pEnts)[I]).parts
Ptr_Free, ((*pEnts)[I]).part_types
Ptr_Free, ((*pEnts)[I]).attributes
ENDFOR
Ptr_Free, pEnts
That should do it. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: IDL Shapefile Object [message #28360 is a reply to message #28295] |
Mon, 03 December 2001 07:15 |
mvukovic
Messages: 63
Registered: July 1998
|
Member |
|
|
David Fanning <david@dfanning.com> wrote in message news:<MPG.1670836a9029670e9897a1@news.frii.com>...
> Mark Hadfield (m.hadfield@niwa.cri.nz) writes:
>
>> Hey, I didn't know you *could* supply arguments to OBJ_DESTROY (though I
>> should have known because it's right there in the OBJ_DESTROY
>> documentation). Has anyone actually written code that *uses* this feature.
>> And if so, why? It seems to me that when you tell an object to destroy
>> itself, then it's up to the object to know how to do it.
>
> I've never used it. (Guess I should make a habit
> of reading the documentation that *is* there!)
> But I can imagine a case for it.
>
> Suppose one of the fields for the object was a
> pointer to some image data. The same image pointer
> might be present in several objects (to save
> copying the huge image). Any decent object cleanup
> routine would certainly free the pointer, but maybe
> you don't want it destroyed because then the other
> objects that are using it wouldn't work properly.
>
> In this case a HANG_ON_DONT_DO_IT keyword on the cleanup
> method might be appropriate.
>
> Cheers,
>
> David
An object should know what heap variables it created, and thus, only
destroy those heap variables (that the object itself created). All
other heap variables that were passed to it from the outside should
not be within its responsabilities.
Mirko
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
