Hiya guys.

As everyone knows, the amount of "memory" being used by
our applications is a pretty variable thing.
(NOTE: I mean 'memory' in the most general sense you can imagine)

And what the Windows TaskManager says we are using, and
various 3DGS variables say we are using is usually different.

So Im looking for some form of correlation 'pattern' between
what TaskManager says and what 3DGS says.

It doesnt need to be EXACT, just a general pattern.
Because Im trying to determine by watching the task manager
how efficient my code is in memory consumption, and also check
for memory leaks INSIDE 3DGS where MY code is faulty.

The TaskManager reports all sorts of spikes and dips that
I SUSPECT are changes in 3DGS's usage, that windows doesnt
report on promptly, OR there is some sort of buffering by 3DGS
in releasing memory BACK TO WINDOWS even if it is no
longer actively using that memory.


I would like to understand APPROXIMATELY what is going on so when
Im watching the task-manager, I know when to ignore the current
values, or wait for an update, or whatever.
I hope you get my drift...


So Im after ANY information / suspicions / theories that anyone has.
If you have links to any outside web-pages and the like that you think
are appropriate, then Im happy to see them too.

Thanks a 'heap' guys...

Nothing accurate information from me, just feelings...
When i investigated memory leaks and i watched 3DGS in TaskManager i felt very good correlation between the memory data showed by F11 and the TaskMan data.

The unclear nature of the "nexus" makes it hard to make conclusions. You have to do some assumptions, and these assumptions will not always be true for all test cases. Therefore making conclusions out of different test results(under the same assumptions) will never show a stable curve. But if you can catch a pattern it could be helpful, and can be categorised under your APPROXIMATE category.

I once ran a series of tests. one of them was with an empty level and the CUBE_MDL. An ent_crate, ent_remove/ptr_remove test. I could not find that pattern because i do not know what does engine do under the hood. I had my task manager setup like this: http://imageshack.us/a/img833/5062/taskmgr.png
private delta shows newly allocated/released amount of memory between previous taskmgr update and the last update.

I do not have exact number any more but creating first entity costed around 350kb, this, I guess because of the mesh and other shared portions of data, then subsequent entity creations SOMETIMES costed 4KB, which is, I assume memory required for the ENTITY pointer and the ENTITY struct(skills,flags,other pointers in the struct) itself. I say "sometimes" because it's not always the case, sometimes delta remains 0, and the total does not change. That could be because that the between task manager updates, the engine releases 4KB memory from somewhere else and allocates new memory for the new entity OR does not release that memory at all and uses it for the entity. This i guess where the nexus comes in to play. Altough a new entity is ent_created no new memory is allocated. It is also same for other way around, ent_removing an entity sometimes does not make any change in the value that is seen on the task manager. Now an interesting part is that when you remove a couple of entities and see no change in memory, there is a couple of different things that can happen:

1. waiting a while releases some memory which is not generally 4kb*ent_removed entity count(it may be greater or less than that).
2. waiting and after seeing there is no change in memory:
-->2.a. releasing an entity more or a couple more entities release some amount of memory. Amount of it seems like related to previously released entities plus the ones you just released(the ones that looked like there was no change in memory)
-->2.b. after removing entities and waiting and seeing that there is no change in memory, ADDING another entity sometimes suddenly releases some memory.


All I can make out of this that is that nexus and/or engine releases and allocates memory in certain chunks.