Relinquish_Memory

Functions

void Relinquish_Memory (void)
 Returns temporary memory (kept internally by HOOPS) to the system. More...
 

Detailed Description

Function Documentation

◆ Relinquish_Memory()

void Relinquish_Memory ( void  )

Returns temporary memory (kept internally by HOOPS) to the system.

DETAILS

As documented in Show_Memory_Usage(), HOOPS retains allocated memory even after items are deleted from the scene-grpah, in order to 'recycle' chunks of memory. Reset_System() can be used to have HOOPS relinquish all of its allocated memory but that effectively shuts down HOOPS. Relinquish_Memory() causes any unused memory to be freed without destroying the existing HOOPS scene-graph.

NOTE

As a rule, it is moderately expensive to call Relinquish_Memory() . The entire list of allocated memory items is searched to determine what can or cannot be freed.

NOTES

Generally, if your HOOPS-based application is going to continue to insert/remove items from HOOPS in an ongoing basis, this function should not be used, even as a means of 'obtaining more memory' for the application. Otherwise HOOPS will simply allocate more memory anyway, and instead of it using its built in memory-manager and allocating from its 'pre-allocated' memory pool, it will just directly allocate it from the OS, which is typically slower. However, if you have a case where HOOPS database interactions have perhaps reached a point of 'stabilization' (i.e. a model is loaded and has been interacted with a bit, and nothing else is going to be loaded, etc...), this function could prove useful by having HOOPS free up its unused portion of allocated memory.

This function should generally NOT be called on 32-bit Windows operating systems, because it can significantly shorten the life of an application. The reason being, that when memory is freed back to the system on 32-bit Windows, the real memory gets freed and defragged by the OS, but the virtual address space does NOT get defragged. If an application keeps allocating and freeing actual system memory during its lifetime, for all intents and purposes memory will 'run out' due to the address space fragmentation, even though actual physical memory might still be available. (This is a somewhat esoteric, yet documented 32-bit Windows OS behavior.) While 64-bit systems do not have the 'virtual address space fragmentation' issue, you typically should avoid calling Relinquish_Memory(), and simply rely on HOOPS to effectively manage its 'allocated' memory during the lifetime of the HOOPS-based application.

Rather then focus on trying to have HOOPS free up memory, it may be better to focus on limiting how much info you put in HOOPS, by tracking it with Show_Memory_Usage()

After a call to this function, the 'in_use' memory will not necessarily equal the amount of 'allocated' memory reported by Show_Memory_Usage(), since HOOPS may still need to retain some memory for various caching purposes.

RESTRICTIONS

See also
Reset_System, Show_Memory_Usage