POV-Ray : Newsgroups : povray.general : best practice question : Re: best practice question Server Time
19 Apr 2024 20:41:05 EDT (-0400)
  Re: best practice question  
From: William F Pokorny
Date: 12 Jun 2020 14:34:04
Message: <5ee3ca9c$1@news.povray.org>
On 6/11/20 3:49 AM, jr wrote:
> hi,
> 
> Alain Martel <kua### [at] videotronca> wrote:
>> Le 2020-06-09 à 06:07, jr a écrit :
>>> I have a macro which expands to an array, eg
>>>
>>> #macro mkArr(...)
>>> .....
>>> array [2] {...}
>>> #end
>>>
>>> which gets assigned, repeatedly, to the same '#declare'd variable.  is this ok
>>> wrt memory management, or is it better to '#undef' the elements, and or the
>>> array, before replacing it wholesale?  is there a difference?  do 'mixed' arrays
>>> behave same as "normal" arrays?
>>>
>> Whenever you assign a new value to any variable, the new value simply
>> replace the old one in the same memory space.
>> The only issue that may arise for memory management, is when you assign
>> a string that don't always have the same length.
>>
>> So, you don't need to #undef.
> 
> no strings in this project.  still not quite clear what happens when "...simply
> replace the old one in the same memory space".  does POV-Ray do "garbage
> collection" at this point, or is the previous value orphaned?
> 
> (I ask because the example is a simplification.  the array returned is dynamic
> and may contain hundreds of results/elements.  my main "problem" is that the
> documentation does not give me any clues.)
> 
>> I don't know for mixed arrays.
>>
>> You may need to #undef if you want to assign a new value of a different
>> type like float to vector or string.
> 
> currently I simply "#declare Arr = array {};", ie overwrite (?) the previous
> content, hence want/need to know what happens to the old values.
> 

I'm not familiar with the new-ish array / dictionary functionality or 
code, but I think POV-Ray will let you know if an undef is required. You 
cannot redefine functions for example, without first an undef(2).

It should be the previous memory gets freed(1) on the new declare if 
POV-Ray allows it. Perhaps proceed as if all OK, and worry about undefs 
if you see memory growth? In such a case, I'd consider the lack of a 
parser error message (or not freeing memory automatically) a bug.

(1) - IIRC memory use is higher with the newer features. Both because 
mixed array elements are all of a size which accommodates the largest. 
And on growth the increments are in some sort of multiple of the 
existing size. Again, not familiar with the code and I have not myself 
used it. All Christoph's work.

(2) - Undefs are are not going to help with memory fragmentation over 
time in any case supposing you are allocating and freeing a large number 
of varying arrays.

Aside: Anyone else find the #declare, #undef (un-define) pairing 
inconsistent. ;-)

Bill P.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.