   Function-local array performance?
  How do I estimate the size threshold at which an array should become a member of the object or static rather than being local to a member function?  For example, from some code using ffmpeg for decoding I've seen, in a member function called every frame there isint linesize[] = {-3 * width, 0, 0, 0};sws_scale(................., linesize);How large an array would one make thread-local static or a member of the function in order to avoid presumably allocating every function call?   
  Such arrays are allocated on the stack (like all local variables) and are thus very quick to allocate. There is no hard and fast answer to this question as it depends how much stack space is available and how deeply nested your function calls are.A 16 byte array like in your example is perfect because it needs populating with data each time and it takes up very little stack space.A 32kb array, on the other hand, might be pushing it and would be better allocated on the heap once and then reused.   ;Quote:Original post by PruneHow large an array would one make thread-local static or a member of the function in order to avoid presumably allocating every function call?This is nothing to do with speed, really, because allocating the array on the stack is trivial (one instruction). It has more to do with how much space is available on the stack.But calling a function is different, anyway: it's not going to copy the array on the stack, but instead just push a pointer. Remember that whole 'pointer decay' thing? Yeah.In case you actually need to make a copy of the array for algorithm correctness, use something like boost::array (and pass it by value).   ;  The main thing that's potentially slow for stack allocated arrays is that any initialization of the array elements will be done each time the function is called. This means an uninitialized array is almost free, but a large array filled with data that doesn't change very often should probably be stored elsewhere.   ;  Adam, you're right, however the picture is far from complete. A local array to a function can give a better speed boost if performance is a concern because it helps the compiler optimize the code better. Otherwise, the compiler assumes aliasing and emits code that is less than the optimal.So basically - it depends on profiling like everything else. Just a couple of things to note for the original poster:1. At least in Windows, default stack space per thread is 1 MB. Every platform has its own threshold. So allocating too much (like 32 Kb) is not a good idea.2. Allocation in the heap is expensive both when allocating and especially when deallocating. Each memory operation is a search on the memory allocator's tables. Not only that, some implementations perform coalesce when freeing memory to defragment the heap.its one of those things that there is no single answer to - you have to test what your hardware and OS are doing and pick a solution both good for performance and also for efficient memory management.If neither performance of fragmentation bother you - just do whatever you need :)That's always the most fun heh   