# Memory allocation speed...

This topic is 4819 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

In my program I have to allocate memory every frame for each object on screen, this memory is then free'd again when the object has been rendered. I am looking for ways to improve the performance of the program and wondered how long it takes in computing terms to allocate and assign memory? For example
unsigned char* SampleBuffer = new unsigned char[BufferSize];

and

memcpy((byte*)(LockedRect.pBits), (byte*)SampleBuffer, BufferSize);


Buffer size is commonly about 800x600x1 = 480000 although it can get to as high as 1024x768x4 = 3145728. Would this be a problem? Thanks in advance. Mark Coleman.

##### Share on other sites
Allocating memory each frame is usually a bad idea. If you need the memory each frame then why delete it after rendering each frame? It's probably better to save that memory until the next frame, building some kind of pool where you store unused memory instead of allocating new memory is usually a good idea with these kind of things. But in what kind of situation do you really need to allocate this memory each frame? I'm guessing it's some kind of bit field for the screen that says if a pixel is affected or something like that. if you give more info on what exactly it is you are trying to do it's easier to say if you're doing the "right" thing ;)

- Damage Incorporated.

##### Share on other sites
First, the question you really need to ask is "is this a problem"? To answer this question:

1. Build your project in release mode.
2. Run it on your minimum-spec target machine.
3. Does it run fast enough? If so, you're done.
4. If not, then run VTune on the program while running the slow parts.
5. Analyze where time is spent, according to VTune profile.
6. If significant time is spent in the idle loop or system idle process, you're likely graphics bound; try running with a smaller window or another graphics card.
7. If significant time is spent in some specific DLL, or a specific function or set of functions in your program, that's where you should optimize.

OK, after doing this, supposing that memory allocation actually is a problem, then you can start thinking about optimizing that. There are two strategies:

1. If you know that you will need to allocate memory for each renderable each frame, you can pre-allocate that memory as part of the renderable. Derive IRenderable from MyRendererStorage which has the data you need, for example. This means there's no allocation whatsoever during runtime, which is good. It also ties your IRenderable to the internal data structure needs of your renderer, which increases coupling, so it's not brilliant, but usually effective enough.

2. Make allocation faster. For example, you can write a linear allocator, which just rounds the size up to 8 and adds to a pointer, taking memory out of a pre-allocated large chunk of memory. If the large chunk runs out, you assert and quit -- pre-allocate large enough to deal with all renderables you could throw at it. This is fairly fast, and caches well (as it's linear), but has a little bit of overhead of storing separate pointers to renderables, and storing data in two places (renderable, and the allocated management record).