What I saw seemed like an unusually high jump in RAM for such a minor change. I’ve been through this exercise many times, so have some experience with it. We’ll see if I find anything…
It appears that guardedalloc and vulkan_memory_allocator are handling most of the heap memory. Is that correct?
Partially, guardedalloc is, the vulkan backend is off by default since it’s still under heavy development so that bit of code is disabled by default, even when enabled it would only manage the memory related to the vulkan graphics stack.
And, (I wish I could think of a way to figure this out so I won’t seem stupid) when Blender runs, who’s in charge? Python or C/C++?
The main entry point of blender is in C/C++ but sometimes the main thread will call to the python library to run some python code which then will be in control for as long as that takes before giving control back.
on that subject I’m also going to go ahead and recommend this book, which I found to be immensely helpful when starting to dive into the blender codebase. It’s a couple of years old at this point but is still very much relevant and will help you understand how the code is organized much better than the wiki does.
@Cal_Niemi are You planing coding here and coming something?
I see You are well with weakness recolonization in practice skills, maybe related area around GPU can be interesting for you to find bad case usages and indicate this in code. I think are issues around pointers and array refresh, reinits, shifts on memory that refreshing computing on CPU/GPU.