Am 07.05.2016 um 10:32 schrieb Jaime Vives Piqueres:

>> I wouldn't be surprised if the memory leaks turned out to be related
>> not so much to /what/ you populate your scene with, but /how/.
> 
>   First, let see if I understand this correctly: in an animation where
> there are the same exact number of objects, and only some objects move,
> the memory consumption should stay stable from the first frame, isn't?
> 
>   If so, I see a little increase from frame to frame on a test I did:
> along 1000 frames, the memory increased some 300K. And in this special
> case, there is only /what/, not any /how/... the movement was calculated
> with the bullet physics playground, and as such there are no
> calculations, no functions, no macros, no splines. Only a different
> include for each frame with the same objects using different matrix values.

Au contraire -- loading 1000 different include files, one for each
frame, is a /remarkable/ "how"!

It would be interesting to know whether you see the same memory increase
if all frames include the same file.

Because, suppose POV-Ray keeps some records on each and every include
files it has seen since its start, and doesn't forget between frames; in
that case an increase in memory consumption is /exactly/ what we'd have
to expect.

And as a matter of fact POV-Ray for Windows /does/ have a mechanism that
may do exactly that, and intentionally so: Ever noticed how, if you try
to render an include file, POV-Ray offers you to instead render the POV
file that you had previously rendered and which includes that file?
Obviously it needs to do /some/ bookkeeping for that stunt.

300K per 1000 frames, that would be 300 bytes per frame, which doesn't
sound too unreasonable for that case: Suppose the mechanism stores the
absolute paths, then a typical file name may have a length of, say, 70
characters. Now suppose the mechanism is part of the code that uses
UTF-16 for encoding, requiring at least 2 bytes per chacater, then
you'll need 140 bytes per filename. Now consider that the mechanism
needs to associate include file names with scene file names, and imagine
that it naively stores a straigtforward list of filename pairs (include
file vs. scene file), and you would have 280 bytes "payload" data stored
for each include file ever seen. An overhead of a few pointers will
easily get you from there to 300 bytes.

Post a reply to this message

Am 07.05.2016 um 10:32 schrieb Jaime Vives Piqueres:

>   If so, I see a little increase from frame to frame on a test I did:
> along 1000 frames, the memory increased some 300K.

BTW, I wouldn't even know how to /measure/ such a tiny increase, with
POV-Ray's memory footprint varying at runtime, apparently quite
randomly, between values as low as about 8 MB and as high as about 24 MB.

Post a reply to this message

> Am 07.05.2016 um 10:32 schrieb Jaime Vives Piqueres:
>
>> If so, I see a little increase from frame to frame on a test I
>> did: along 1000 frames, the memory increased some 300K.
>
> BTW, I wouldn't even know how to /measure/ such a tiny increase,
> with POV-Ray's memory footprint varying at runtime, apparently quite
> randomly, between values as low as about 8 MB and as high as about 24
> MB.
>

   My fault... it wasn't 300K but 300MB. Now I used htop and even with a
static scene the memory reported in use by POV-Ray increases as the
animation progresses. Yes, the reported memory varies randomly up and
down, but is definitely going up in the long run.

Post a reply to this message

Am 05.05.2016 um 16:22 schrieb ratneshmadaan:
> I am rendering about 100k frames using an ini file of the same object type, each
> having a random (in a box) configuration of the object, no of objects, camera
> location, light source, viewing angle etc. Issue is RAM consumption increases
> monotonically. I don't know what garbage value isn't being thrown. Is there a
> macro to delete stuff manually at the end of a .pov file, or any other good
> practices? (new to povray here)

As mentioned in another thread, the newest version should fix the leak
(presuming it's the same Dick was observing); Windows binaries are
currently in the making, and should be available just a few minutes from
now at
https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8600570 (the
32-bit binaries are already there).

Post a reply to this message