Is it slow on the iPhone to do a lot of mallocs and frees?

Question

Hey guys, I was working on some particle systems and this was the only way I could figure out to set up the arrays:

if (vertices){
  free(vertices);
 }
 if (textures){
  free(textures);
 }
 vertices = malloc(sizeof(point3D) * 4 * [particles count]);
 textures = malloc(sizeof(point2D) * 4 * [particles count]);

The particles constantly change so a new size of array needs to constantly be created at about 60 fps. Is this a bad way of doing things? Could this cause my app to slow down or cause memory thrashing? When I run it under instruments it doesnt look to bad but it is running on the simulator on my mac. Is this ok or is there another way I could be doing this?

**EDIT Ok I went in and rewrote the system it estimates the max amount of particles at creation. Then it uses that to allocate arrays. This system has the trade off that it often overestimates the memory needed by quite a bit but only calls malloc once. I figured it was not that big of a trade of since a maximum realistic overestimate would be like 100 floats, which is not too bad. Thanks for the help guys.

Answer 1

In that case, you'd probably want to keep that memory around and just reassign it.

Answer 2

Try starting with an estimated particle count and malloc-ing an array of that size. Then, if your particle count needs to increase, use realloc to re-size the existing buffer. That way, you minimize the amount of allocate/free operations that you are doing.

If you want to make sure that you don't waste memory, you can also keep a record of the last 100 (or so) particle counts. If the max particle count out of that set is less than (let's say) 75% of your current buffer size, then resize the buffer down to fit that smaller particle count.

Answer 3

You don't need to remalloc unless the number of particles increases (or you handled a memory warning in the interim). Just keep the last malloc'd size around for comparison.

Answer 4

Allocating memory is fast relative to some things and slow relative to others. The average Objective-C program does a lot more than 60 allocations per second. For allocations of a few million bytes, malloc+free should take less than a thousand of a second. Compared to arithmetic operations, that's slow. But compared to other things, it's fast.

Whether it's fast enough in your case is a question for testing. It's certainly possible to do 60 Hz memory allocations on the iPhone — the processor runs at 600 MHz.

This certainly does seem like a good candidate for reusing the memory, though. Keep track of the size of the pool and allocate more if you need more. Not allocating memory is always faster than allocating it.

Answer 5

As hotpaw2 mentioned, if you need to optimise you could perhaps do so by only allocating if you need more space i.e.:

particleCount = [particles count];
if (particleCount > allocatedParticleCount) {
  if (vertices) {
    free(vertices);
  }
  if (textures) {
    free(textures);
  }
  vertices = malloc(sizeof(point3D) * 4 * particleCount);
  textures = malloc(sizeof(point2D) * 4 * particleCount);
  allocatedParticleCount = particleCount;
}

...having initialised allocatedParticleCount to 0 on instantiation of your object.

P.S. Don't forget to free your objects when your object is destroyed. Consider using an .mm file and use C++/Boost's shared_array for both vertices and textures. You would then not require the above free statements either.

Answer 6

I'll add another answer that's more direct to the point of the original question. Most of the answers prior to this one (including my own) are very likely premature optimizations.

I have iPhone apps that do many 1000's of mallocs and frees per second, and they don't even show up in a profile of the app.

So the answer to the original question is no.