POV-Ray : Newsgroups : povray.general : memory leak in 3.1g? : Re: memory leak in 3.1g? Server Time
11 Aug 2024 07:16:53 EDT (-0400)
  Re: memory leak in 3.1g?  
From: Steve
Date: 21 Aug 1999 13:39:34
Message: <37BED4DF.6FF2C026@ndirect.co.uk>
So basicly I've got to get a hell of a lot more memory before
rendering that scene which takes 8 days to parse, the annoying
thing is that it only takes two and a half hours to parse the
first half, I know this because of putting #dbugs in to monitor
the parsing.  


Thorsten Froehlich wrote:
> 
> In article <37BDD20B.AAF0364A@ndirect.co.uk> , Steve <sjl### [at] ndirectcouk>
> wrote:
> > When parsing a scene that needs to swap for a few days it sounds
> > asthough the machine is working something out, placing an answer
> > to that in the swap file, reading that answer in order to find
> > out where an object goes or something, deleting that answer, and
> > putting the object place info inot the swap file and then
> > starting over again for the next object.
> 
> I think you misunderstand what a swap file does: When physical memory gets
> low the operating system (not POV-Ray!) will store some blocks of memory on
> a mass storage device (usually harddisk) and adjust the memory map of the
> CPU so the larger memory still appears to be there even for the processor.
> When it tries to access memory that is on disk, an exception handler (= a
> function) of the OS will be called and it will move some other blocks of
> memory to disk and move those needed from disk to memory. This processes is
> completely transparent to POV-Ray as it is to any other application.
> 
> > Would it be possible to have POV use memory until it's full and
> > then instead of starting to swap, putting say the last ten
> > percent of memory into the swap file and there fore having ten
> > percent of memory to play with unitl it's full and doing the same
> > again over and over rather than constantly reading and writing to
> > the swap file.
> 
> As said before, the swap file is managed by the operating system. Most
> operating system memory managers can determine efficiently which blocks of
> memory to move to disk and which are needed often and therefore should stay
> in memory.
> 
> > I don't know if this would be possible or not, but it would speed
> > those types of render up considerably.
> 
> While a specialized memory manager could surely squeeze out a few percent,
> it would basically require to write a whole operating system as memory
> management is obviously one of the core functions of any OS!
> 
>     Thorsten
> 
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
> 
> Visit POV-Ray on the web: http://mac.povray.org

-- 
Cheers
Steve

email - mailto:sjl### [at] ndirectcouk

%HAV-A-NICEDAY Error not enough coffee. 

web:  http://www.ndirect.co.uk/~sjlen/


Post a reply to this message

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