Memory garbage collector
Vely memory allocation is tracked and automatically released at the end of a request
. This includes any memory allocated by Vely itself and any memory allocated by Vely statement_APIs
, even if memory is no longer accessible to program, thus preventing memory leaks; this is important for stability of long-running processes. Memory needed for cross-request purposes, such as prepared database statements or process configuration data, is kept for the life of the process.
No memory reuse
Any of the Vely statement_APIs
that returns newly allocated memory will always create new memory. In other words, if you use variable "result" (that has already been allocated by another statement) to hold the result, the previously allocated memory for it will be ignored, and new memory allocated, meaning Vely will not attempt to reallocate memory. The reason for this is to reduce errors and fatal crashes that may result from passing non-Vely allocated pointers, or bad pointers. This will not create a memory leak because Vely keeps track of all such allocated memory and all of it will be deallocated at the end of the request
. If you allocate large amounts of memory in a loop, you can always delete it (using delete-mem
), but in general that is rarely needed.
No freeing of memory
Your application is request-driven, meaning it works by issuing requests, either to the server or as a command-line invocation. Vely automatically frees all memory at the end of each request. Because Vely tracks and releases used memory, you generally should not free memory used by various statements, even when "delete" is provided. There are only a few exceptions to this rule, and the most common one is if your request is using large amounts of memory in a long-running fashion (such as in a loop with many iterations), and it makes sense to release the memory as the request is being fulfilled in order to prevent memory exhaustion or performance degradation; in all other cases you should let Vely free memory for you.