Am 2016-05-05 13:12, also sprach clipka:

> Generally I'd expect the current master branch to have /fewer/ memory
> leaks than the 3.7 stable. But there's always the possibility that I
> might be mistaken.

I can't comment on the /fewer/ than 3.7, but the latest pvengine*.exe 
leaks pretty bad.  I mentioned once that my workflow includes exiting 
and restarting povwin every couple hundred to 1000 frames rendered.    I 
notice about a 50-100KB leak per frame rendered.  Even when the render 
job is done is doesn't give back the memory.  After povwin consumes 2GB 
of leaked memory, it gets pretty sluggish. (I have 16GB of memory.)
For production, I use povconsole which renders one frame per call, so I 
don't care about leaks there.

I was always a little surprised that Jaime didn't weigh in on this 
issue. I figured with the heavy complicated scenes he makes, he must 
notice this. (Although I've never heard him complain about anything. ;) )
-- 
dik

Post a reply to this message

Am 06.05.2016 um 03:25 schrieb dick balaska:

> I was always a little surprised that Jaime didn't weigh in on this
> issue. I figured with the heavy complicated scenes he makes, he must
> notice this. (Although I've never heard him complain about anything. ;) )

From what I see, Jaime is mainly into stills, where leaks are certainly
less of a problem, even when the scenes are much more complex.

Also, any observations that might help identify the leaks are more than
welcome. I'd expect most leaks to be specific to the use of particular
features rather than constant per-frame overhead.

My understanding from your description is that memory consumption not
only rises during animation rendering, but remains high even after the
final frame has finished, right?

If you could provide me with a scene that is guaranteed to exhibit lots
of leakage in the most recent Windows binaries and isn't too slow to
render, maybe along with a bit of technical information on how much
leakage you observe, I'd appreciate that as well. I don't do any serious
animations work with POV-Ray myself, so I have only very simple test
scenes to go by, which do not seem to demonstrate any increase in the
memory footprint that would stand out among the normal random
fluctuations seen in the task manager.

Feel free to email any helpful animation scenes to "christoph", at
"lipka-koeln" in the "de" domain.

Post a reply to this message

> From what I see, Jaime is mainly into stills, where leaks are
> certainly less of a problem, even when the scenes are much more
> complex.

   Yes, I did very few animations, but none recently. With stills I never
noticed anything strange about memory usage. I will try some of my old
animations this weekend, to see if I can confirm this...

--
jaime

Post a reply to this message

Am 2016-05-05 22:50, also sprach clipka:
>
> If you could provide me with a scene that is guaranteed to exhibit lots
> of leakage in the most recent Windows binaries and isn't too slow to
> render, maybe along with a bit of technical information on how much
> leakage you observe, I'd appreciate that as well. I don't do any serious
> animations work with POV-Ray myself, so I have only very simple test
> scenes to go by, which do not seem to demonstrate any increase in the
> memory footprint that would stand out among the normal random
> fluctuations seen in the task manager.

My art is all csg spheres and boxes, cones and torii. No radiosity or 
modern features.  I will whip something off. (Maybe I can put 1000 
spheres *behind* the camera).

I never thought of the leak as animation specific, just the act of 
calling the renderer, which is why I thought of Jaime.  Maybe it is 
related to +SF10 +EF20.



-- 
dik

Post a reply to this message

Am 06.05.2016 um 21:32 schrieb dick balaska:
> Am 2016-05-05 22:50, also sprach clipka:
>>
>> If you could provide me with a scene that is guaranteed to exhibit lots
>> of leakage in the most recent Windows binaries and isn't too slow to
>> render, maybe along with a bit of technical information on how much
>> leakage you observe, I'd appreciate that as well. I don't do any serious
>> animations work with POV-Ray myself, so I have only very simple test
>> scenes to go by, which do not seem to demonstrate any increase in the
>> memory footprint that would stand out among the normal random
>> fluctuations seen in the task manager.
> 
> My art is all csg spheres and boxes, cones and torii. No radiosity or
> modern features.  I will whip something off. (Maybe I can put 1000
> spheres *behind* the camera).

What -- no functions? No macros? No arrays? No spline-based movement? ;)

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/.

> I never thought of the leak as animation specific, just the act of
> calling the renderer, which is why I thought of Jaime.  Maybe it is
> related to +SF10 +EF20.

Nah, the +SF and +EF options don't have much of an effect on the way
POV-Ray operates; it just changes how it computes the frame_number and
clock, that's all.

Post a reply to this message

> 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.

--
jaime

Post a reply to this message

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