Glynn Clements wrote:
Markus Metz wrote:
I remember a discussion in the dev ml, I think with the osgeo4w
installer, that memory allocated with malloc/calloc/realloc should be
free-d with free, not G_free. If this is the case, then there is a
problem in the vector libs, because space for a struct line_pnts * is
allocated with calloc and free-d with G_free, and relevant (or all)
calls to malloc/calloc/realloc/free in diglib should be replaced with
G_malloc etc. What to do?
GRASS code should always use the G_* versions unless there is a clear
reason not to, e.g. if the pointer will be passed to an external
library which will assume ownership of it.
OK, so lib/vector/diglib needs to be updated. What about dglib and
rtree? AFAICT they are written such that the code can be used as
external standalone libraries and not a single G_*() version is used, I
think.
Single-instance allocations don't need to be free()d; they can remain
until the process terminates.
Explicitly freeing memory when termination is imminent is a waste of
resources (e.g. CPU cycles, and I/O bandwidth in the case where free()
causes swapped-out memory to be swapped back in). It's colloquially
referred to as "rearranging the deckchairs on the Titanic".
Clear enough, thanks for the example!
If Vect_set_release_support() does not cause a severe time penalty, I
would recommend to use it. IMHO 73,854,014 - 444,026 (previous result)
bytes = ca. 70 MB lingering around in memory is a bit unnecessary.
That should only be done if vectors will be closed signficantly prior
to termination, e.g.:
for (i = 0; i < nvects; i++) {
vect = Vect_open_old(...);
...
Vect_close(vect);
}
Can we add this to the Programmer's manual under GRASS 6 Vector
Architecture where Vect_set_release_support() is mentioned or have I
missed something?
Markus M
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
