<p>Whenever there's too much churn of things being created and destroyed, regardless of the specifics of the situation, a common way to dealing with this is to make free object pools.</p>

<p>How these work is when you are done using something, instead of actually freeing or destroying it, you put it back into a list or array of "free objects".</p>

<p>When you need a new object of a specific type, you check the object pool to see if there's a free one lying around.  If there isn't one there, you create a new one the "expensive" way and use it.  When you are done with it, you put it in the free pool for use in the future.</p>

<p>A possible issue with free object pools is that you may have a spike in objects for some reason and then you are left with a ton of unused objects sitting in a free pool that will never be needed again.  In situations like this, you can keep track of how long (in number of frames for instance) since an object was last used, and if they get over a certain unused age, free them from the object pool.</p>

<p>PS - make sure and profile your code to find what the ACTUAL performance bottlenecks are before attempting to solve problems.  Optimizing without profiling before (to find the problem) and after (to verify you improved things, and knowing by how much) won't get you very far (:</p>

CC BY-SA 3.0
2017-10-05T08:40:44.750Z
That could be a nice approach, I think we don't have inconsistencies on that aspect, but as I said, there are quite a few allocs and deallocs. And yeah, I have to start doing some profiling but I really think that this could be a potential improvement :). Thanks!
Nacho
CC BY-SA 3.0
2018-03-04T06:16:54.823Z
You can make your pool allocate groups of objects, say 64 objects at a time when requesting an object, by linking the first object in that block to your 'used list' and the other 63 to your 'free list' to avoid hammering the memory allocator.
PaulHK
CC BY-SA 3.0
2017-10-04T19:59:18.963Z
2017-10-04T19:59:18.963Z
Alan Wolfe
<p>I recently finished the base implementation of a DX12 rederer and I started to think in ways of improving the performance. I think that one problem that my implementation has, is memory fragmentation, as I mostly perform "single" allocations for my resources. During run-time some resources are deleted and recreated which I guess will cause even more memory frag. There are quite a few articles online about writing system memory managers but I've never encountered something like that for video memory and GPU resources. </p>

<p>Could anyone explain the basics of a system like this? 
Thanks!</p>

<p>EDIT:
I had this link laying around: <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/mt613239(v=vs.85).aspx" rel="nofollow noreferrer">Memory Management in Direct3D 12 | Windows Dev Center</a>. That gives some good general information about the topic.</p>

<gpu><memory>
Handling GPU resource management
Nacho
# Handling GPU resource management

(Asked by: username_0 on 2017-10-04)

I recently finished the base implementation of a DX12 rederer and I started to think in ways of improving the performance. I think that one problem that my implementation has, is memory fragmentation, as I mostly perform "single" allocations for my resources. During run-time some resources are deleted and recreated which I guess will cause even more memory frag. There are quite a few articles online about writing system memory managers but I've never encountered something like that for video memory and GPU resources.

Could anyone explain the basics of a system like this?
Thanks!

EDIT:
I had this link laying around: [Memory Management in Direct3D 12 | Windows Dev Center](https://msdn.microsoft.com/en-us/library/windows/desktop/mt613239(v=vs.85).aspx). That gives some good general information about the topic.

**Tags:** gpu, memory


---

## 1 answers

### Answer by username_1 on 2017-10-04. Score: 3

Whenever there's too much churn of things being created and destroyed, regardless of the specifics of the situation, a common way to dealing with this is to make free object pools.

How these work is when you are done using something, instead of actually freeing or destroying it, you put it back into a list or array of "free objects".

When you need a new object of a specific type, you check the object pool to see if there's a free one lying around. If there isn't one there, you create a new one the "expensive" way and use it. When you are done with it, you put it in the free pool for use in the future.

A possible issue with free object pools is that you may have a spike in objects for some reason and then you are left with a ton of unused objects sitting in a free pool that will never be needed again. In situations like this, you can keep track of how long (in number of frames for instance) since an object was last used, and if they get over a certain unused age, free them from the object pool.

PS - make sure and profile your code to find what the ACTUAL performance bottlenecks are before attempting to solve problems. Optimizing without profiling before (to find the problem) and after (to verify you improved things, and knowing by how much) won't get you very far (:

> **Comments:**
> **username_0**: That could be a nice approach, I think we don't have inconsistencies on that aspect, but as I said, there are quite a few allocs and deallocs. And yeah, I have to start doing some profiling but I really think that this could be a potential improvement :). Thanks!  
> **username_2**: You can make your pool allocate groups of objects, say 64 objects at a time when requesting an object, by linking the first object in that block to your 'used list' and the other 63 to your 'free list' to avoid hammering the memory allocator.  

---

