On 2/10/2016 2:19 PM, clipka wrote:
> Am 10.02.2016 um 19:00 schrieb dick balaska:
>
>> povwin 3.7.1-alpha.8358383+av65.msvc14.win
>> I think you built it.
>
> To be precise, I didn't -- it was AppVeyor that did. All builds
> identifying as "+av<number>" are automated builds generated by that service.
> But yes, I did authorize the build and its distribution.

tomayto, tomahto.

> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8463913%2Bav107
>
Running the same render set.
boot idle:
Mem Usage (KB) 16,028
VM Size (KB)    7,704

During first frame:
Mem Usage (KB) 190,400
VM Size (KB)   243,388

2nd:
Mem Usage (KB) 221,928
VM Size (KB)   273,868

3rd:
Mem Usage (KB) 253,004
VM Size (KB)   304,468

4th:
Mem Usage (KB) 286,372
VM Size (KB)   340,000

aborted render.  Hey, it gave back lots of memory then. Idling at:
Mem Usage (KB) 185,532
VM Size (KB)   197,652

Post a reply to this message

Am 10.02.2016 um 22:32 schrieb dick balaska:

>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8463913%2Bav107
>>
>>
> Running the same render set.
> boot idle:
> Mem Usage (KB) 16,028
> VM Size (KB)    7,704
> 
> During first frame:
> Mem Usage (KB) 190,400
> VM Size (KB)   243,388
> 
> 2nd:
> Mem Usage (KB) 221,928
> VM Size (KB)   273,868
> 
> 3rd:
> Mem Usage (KB) 253,004
> VM Size (KB)   304,468
> 
> 4th:
> Mem Usage (KB) 286,372
> VM Size (KB)   340,000
> 
> aborted render.  Hey, it gave back lots of memory then. Idling at:
> Mem Usage (KB) 185,532
> VM Size (KB)   197,652

I presume you're currently giving it a more challenging test?

Post a reply to this message

On 2/10/2016 5:46 PM, clipka wrote:

> I presume you're currently giving it a more challenging test?

Nah. I discovered an object position problem (I think related to my 
constantly switching between 23.976 and 30 fps).  My renderfarm is 
cranking a 2 week run and I didn't want to waste 12 hours of cpu time on 
my fastest box. ;)
complete:1028 todo:2315     FPH:10.70  lastday:6.2   lasthour:7 
ETC:9 days   (15 days, 13 days)

I had looked at some leak detectors a while back.  I should look 
again... (In 1989 I paid $2K for Purify.  If we can get povwin running 
on Windows 3.1, *that* will find all leaks)

dik

Post a reply to this message

Le 16-02-10 19:12, dick balaska a écrit :
> On 2/10/2016 5:46 PM, clipka wrote:
>
>> I presume you're currently giving it a more challenging test?
>
> Nah. I discovered an object position problem (I think related to my
> constantly switching between 23.976 and 30 fps).  My renderfarm is
> cranking a 2 week run and I didn't want to waste 12 hours of cpu time on
> my fastest box. ;)
> complete:1028 todo:2315     FPH:10.70  lastday:6.2   lasthour:7 ETC:9
> days   (15 days, 13 days)
>
> I had looked at some leak detectors a while back.  I should look
> again... (In 1989 I paid $2K for Purify.  If we can get povwin running
> on Windows 3.1, *that* will find all leaks)
>
> dik
>

It's a tool to detect memory leak in 16 bits applications running under 
a 16 bits OS with 32 bits extention. Not sure if it can work for 32 bits 
applications, and would be surprised if it can work at all for 64 bits ones.

Post a reply to this message

I have seen this happen, but only occasionally. And I have a workaround.

Some while ago one of my images (I render at 2048x1536) crashed POV-Ray (XP,
intel quad core - yes, I know, I need to leave the stone age!) by eating up the
memory (gradual climb from 1.3 gb to 1.7 gb over 24 hours). It was a tree scene
so there were lots of objects. I subsequently discovered that by pausing the
render and going off to do something else on the very same machine the reported
memory usage dropped and then picked up again after restarting the render, but
at a much lower value, allowing the render to complete.

Is this the same problem, or something else again?

Post a reply to this message

Am 25.03.2016 um 13:43 schrieb Simon J. Cambridge:
> 
> I have seen this happen, but only occasionally. And I have a workaround.
> 
> Some while ago one of my images (I render at 2048x1536) crashed POV-Ray (XP,
> intel quad core - yes, I know, I need to leave the stone age!) by eating up the
> memory (gradual climb from 1.3 gb to 1.7 gb over 24 hours). It was a tree scene
> so there were lots of objects. I subsequently discovered that by pausing the
> render and going off to do something else on the very same machine the reported
> memory usage dropped and then picked up again after restarting the render, but
> at a much lower value, allowing the render to complete.
> 
> Is this the same problem, or something else again?

That exactly matches the scenario I described.

Post a reply to this message