C / C ++ memory allocation

This situation is not sufficient to determine the "best" approach.

(1) At a given time, the total size of the set of objects is known. Thus, the required memory can be allocated in one clock cycle.

If all distribution occurs in the initial part of the program, this fact does not help us (unless it is important to speed up the load time). It doesn't help if the program frequently destructs and creates new objects, because memory allocators never release their heap memory back to the OS; he simply releases it for his own future use.

The only time this information is useful is when all allocation and deallocation of objects that occur during the program's lifecycle are of the same object type. In this case, the implementation of the memory pool will improve performance, since the search for the next available slot for allocation is always O(1)

. Here is an example of implantation ( source ).

If you also know the total size of objects for each object type, then multiple memory pools will be helpful as well. If not, you can always round all objects to the maximum object size and improve performance (using a memory pool) at the expense of wasted memory.

(2) Memory ownership must be allocated to each individual object, and the time of release (release) is not specified.

The timing of working with objects is very difficult and the best approach depends on these three questions:

• How many links does one object have?
• How many times has this object been passed from hand to hand?
• Do your object graphics contain cycles?

If the answers to these questions are: "Couple, not many and not," then it std::shared_ptr<>

can be very useful. However, if the number of references is not so small, or if the object is constantly passed from hand to hand, then reference counting can cause a large overhead of counting the references each time the hand is passed. If you have loops in an object graph, a memory leak occurs... In such a case, a garbage collection solution is likely to have better performance and be easier to manage (see Boeham for C and C ++).

My adhoc approach is some type of allocated chunk reference counting. Each time the object is free, the reference count is decremented. When its zero releases a large chunk.

Given the fact that it free()

doesn't really free memory from the OS, I don't see any benefit from this approach. You just have more management overhead without gaining any performance. You didn't mention in your question about the need to free memory for the OS, so I guess this is not a problem.

Is there some pattern or common practice that would be more appropriate?

The most significant improvement you can achieve is the elimination of the need to use assembly in memory management as it is intended for general use. This takes everything into account and therefore has a relatively low performance. For example, managing synchronization between threads.

If you are not using more than one thread and the memory pool solutions apply to you, use them; they will probably have better performance and they are pretty basic. If the memory pool is not applicable and / or you are using many threads in your program, I will go for one of the many alternative memory allocators. A good multi-threaded memory allocator I know of is Hoard .