You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To increase memory efficieny mem_store uses memory reuse. It is somewhat naive. (Keeping a vector with old objects.) It can prevent a slow delete/new cycle, but I also doubt how often it is used.
STL memory pools might increase its efficiency. By also leveraging memory arenas and preventing memory fragmentation. Available in the STL under pmr.
When I mentioned it, Sicco reflected that this was only supported by STL containers. This is not true, but I can understand where the confusion comes from.
The problem you need to tackle is that STL memory pools give you a custom allocator. (A different one from the default one used when calling new.) Containers will usually still call to new interally. Thus you need containers that can use a custom allocator. These are called Allocator Aware containers/objects or AA containers/objects. The STL provides these as pmr::string and pmr::vector for example.
If your AA container stores custom objects, these must also be AA. This is only true is that object makes calls to new for memory or uses attributes that do that. You can make your custom objects AA relatively simple. You can then also think what should happen if you move or copy from a different allocated resource. If you require localization, move from a different allocator must copy, otherwise, maybe not. (See link below.)
Keep in mind that in this instance it is not so problematic if allocators are mixed. It is the same memory in the end. No weird hardware that requires a custom allocator. You should only be aware that memory management is performed by the same allocator that claimed it.
To increase memory efficieny mem_store uses memory reuse. It is somewhat naive. (Keeping a vector with old objects.) It can prevent a slow delete/new cycle, but I also doubt how often it is used.
STL memory pools might increase its efficiency. By also leveraging memory arenas and preventing memory fragmentation. Available in the STL under pmr.
When I mentioned it, Sicco reflected that this was only supported by STL containers. This is not true, but I can understand where the confusion comes from.
The problem you need to tackle is that STL memory pools give you a custom allocator. (A different one from the default one used when calling new.) Containers will usually still call to new interally. Thus you need containers that can use a custom allocator. These are called Allocator Aware containers/objects or AA containers/objects. The STL provides these as pmr::string and pmr::vector for example.
If your AA container stores custom objects, these must also be AA. This is only true is that object makes calls to new for memory or uses attributes that do that. You can make your custom objects AA relatively simple. You can then also think what should happen if you move or copy from a different allocated resource. If you require localization, move from a different allocator must copy, otherwise, maybe not. (See link below.)
Keep in mind that in this instance it is not so problematic if allocators are mixed. It is the same memory in the end. No weird hardware that requires a custom allocator. You should only be aware that memory management is performed by the same allocator that claimed it.
https://www.cppstories.com/2020/08/pmr-dbg.html/
PS. When refactoring mem_store, also keep in mind #23.
The text was updated successfully, but these errors were encountered: