🚀 go-pugleaf

Sara T. wrote:

> If my application takes a lot of memory and never
>free (although I free up in my code), system will be slow down and cannot
>run another application in the same machine at all.
>
>Does it have a possible to manage this problem?

1) Use stack-based variables where you can instead of new or malloc.
I think Windows gives each thread 1 MB of stack space, so use it.
I often use
{	char message[128];
	sprintf( message,"Format"));
}
where I know for sure that message is going to be  less than 80;
I also regularly have structures on the stack that are long[50][132];
If you don't need the data to hang around after you leave a routine,
put it on the stack.


2) Allocate big chuncks of memory, and then break them up into the
smaller pieces your thread needs.
BYTE*Whole=malloc((28*sizeof(long))+sizeof(struct1)+sizeof(struct2));
long*One = Whole;
long*Two = Whole+sizeof(long);
struct1*S1 = While+28*sizeof(long);
	Use them
free(Whole);


3) Use the WinAPI
long*One = GlobalAlloc( GMEM_FIXED ,sizeof(long) );
GlobalFree( One );
But it's better to alloc arrays, and put small variables on the stack.
I prefer GMEM_FIXED because it returns an address instead of a handle,
and handles are in short supply, so don't use GMEM_MOVEABLE unless you
really need it.


4) This probably applies to all methods of allocation:  Free in the
reverse order.
	One = malloc()
	if( One )
	{	Two = malloc()
		if( Two )
		{	Three = malloc()
			if( Three )
			{	free(Three)
			}
			free(Two)
		}
		free(One)
	}
This gives the garbage collector the best shot at restoring the free
memory chain.


5) I'll say it again. Use a fixed set of (16) threads that allocate
their data once, then reuse it, only releasing the data (and
terminating) when the program is exiting.