Sorry for replying to my own post, but since Thorsten and Mark didn't get
my point (which is probably due to my limited knowledge about the English 
language) I will give a more detailed description of my idea.

Thomas Willhalm <tho### [at] willhalmde> writes:
> 
> "Thorsten Froehlich" <tho### [at] trfde> writes:
> >
> > Whenever I profiled, I found that POV-Ray spends a lot of time doing memory
> > allocations...
> 
> Couldn't it be useful to have two methods for allocation memory?
> 1) the POV_MALLOC used so far
> 2) a new method of memory that can only be freed on exit of the program.
> 
> With method 2), POV-Ray can allocate large parts of memory instead of little
> chunks. The size of the "little chunks" doesn't matter anymore and therefore
> needn't be stored. This decreases memory consumption and its handling
> by the OS. The "large parts" could be handled by a linked list. Only for the
> last part -- the current one -- a pointer to the last byte (word) that is 
> used is necessary.

I imagine that there are a lot of objects in POV-Ray for which memory is 
allocated once and used until the end of the rendering. To give a concrete
example, imaging a box being parsed. The corresponding memory is allocated
at this time. The memory will be used until rendering finishes.

Now, I make the following assumption: For a lot of objects (in the sense of
programming) we can guaranty that we will use them until the end of the
rendering. This might be the case for objects (in the sense of POV-Ray),
textures, density maps and so on.

After accepting this assumption my idea comes into play: Why should I store
the necessary information to free the memory of every single object when
I will free them all at once? So, let us reserve a large part of memory 
(e.g. 30 MB). When an object is created (i.e. memory is allocated) we put it 
on top of the memory used to far. All we need is to store a pointer to the 
last address that has been used, because we will free our large part of 
memory all at once (when the rendering is finished).

The problem is of course that we don't know at the beginning of parsing,
how much memory we will need. Thus, we have to split the memory into 
smaller parts (e.g. 64 KB). This is where I want to use a linked list:
to connect the parts of memory. We will use this linked list only once
when freeing the memory at the end of the rendering. That's why this method
is still in O(n). (Allocating memory for a new object takes constant time
and should be faster than the standard way.)

What Thorsten writes about the memory management in POV-Ray for Mac is very
similar to what I suggest -- except that I want to "forget" where the
memory belongs to and the size of the corresponding object. As mentioned in
the introduction, I expect this method to work only for some (perhaps even
most) objects in POV-Ray.

I hope that my description is much clearer now.
Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message