The thing is that most of the documentation seems to talk about spawning Actors etc, and how to manage those which is different to what I need.
I am wondering if there are functions in UDK which allows me to provide a block of memory which I then new & delete from later? Or is there some other scheme I should be using for managing my memory?
I did note this:
Memory.h / FMemory:: Use the Memory.h
functions!
Do not use c++ level memory
functions! Memory.h contains UE4 C++
versions of C++ memory management
functions that are maintained by
Epic as the engine evolves.
So do I simply just use FMemory::Malloc & Fmemory::Free? How do I call constructors on my objects I want to use? new(myMemory) MyClass(construct) ?
How do I control life cycle? Do I need to worry about fragmentation?
The thing is that most of the
documentation seems to talk about
spawning Actors etc, and how to manage
those which is different to what I
need
Maybe you should tell us what you need.
UObjects should be created via NewObject or SpawnActor or whatever… as the wiki says.
FMemory::Malloc and FMemory::Free are available for any use in the normal C-like way, but of course require you to manage the memory and invoke constructors yourself.
new and delete can be used for ‘normal C++ classes’ (not UObjects/actors) - they are overridden to use FMemory::Malloc and FMemory::Free so they will not be using the C runtime.
TSharedPtr and TUniquePtr can be used similarly to std::shared_ptr and std::unique_ptr to manage the lifetime of your objects.
You can use containers like TArray and TMap for managing collections of your objects. Containers can also be provided with an allocator template parameter to further control your memory usage.
There are some specialised pooled allocators and the like too, but I think the above advice is probably sufficient for anything involving constructors (which is all I have to go on).
Fragmentation is always a concern in a system heavy on runtime allocation, but we tend only to concern ourselves with it when it noticeably affects the user experience.
Thanks. I would like to know if I can allocate a subsystem a block of memory for which it can allocate / deallocate into and limit the problems with fragmentation? As I know the life cycle of that system I can clean it up periodically, when it’s completed it’s processing, and reset it’s memory allocator again.
This is useful for items which are handling network streams for example. I need a block of memory to receive a network response, I want to allocate memory blocks as I transform that data, before finally allocating it’s final transformed state.
I then wish to reset the memory allocator back down and start the processing again. In effect a “clear all” which happens at a life cycle different to that of the level.
We don’t have any arena-based allocators if that’s what you mean. The closest is probably the TSparseArray container, though obviously - being a container - that is limited to homogeneous allocations of a single object type.
Fragmentation is always a concern in a system heavy on runtime allocation, but we tend only to concern ourselves with it when it noticeably affects the user experience.
Hi, I’d like to make sure of this statement. Does it mean that fragmentation should only be concerned by Epic staff? Which means that users like us doesn’t need to worry about it? For example, if I uses Blueprint’s Add/Remove Component constantly, would it cause fragmentation? Thanks!
I mean that when fragmentation starts to result in a perceptual change to performance or behaviour, and those allocations are beyond of the control of the engine, we may look to optimising our internal allocators to cope with those patterns.
Our allocators are already pretty good at caching the majority of small allocations so that you never see it. I can’t speak for BP’s Add/Remove component, but as they are likely to involve small allocations, it’s likely they will make good use of our allocator’s cache.
In any case, as a user, striving to limit the amount of extraneous allocations you do can never be a bad thing for the performance of your title.
