[Echelon9]

I've recently pruned from the code base a number of similar code patterns, best exemplified by:

Code: [Select]

--- trunk/fs2_open/code/graphics/gropenglshader.cpp 2011/10/17 13:01:48 7914
+++ trunk/fs2_open/code/graphics/gropenglshader.cpp 2011/10/17 13:07:24 7915
@@ -504,8 +504,6 @@
  bool main_vert = cf_exists_full("main-v.sdr", CF_TYPE_EFFECTS) != 0;
  bool main_frag = cf_exists_full("main-f.sdr", CF_TYPE_EFFECTS) != 0;
 
- GL_shader.reserve(Num_shader_files+1);
-
  for (idx = 0; idx < Num_shader_files; idx++) {
  bool in_error = false;
  opengl_shader_t new_shader;
Broadly, STL types handle their own in-memory locations and reallocations. While STL types do require a copy/realloc operation when they fully utilise their capacity() this is an operation best left to the underlying implementation of the STL on your system.

Why?

• If we do manually set how much to increment the reserve() operation, we may cause unnecessary memory paging. See 'Effective STL' by Myers, Item 14, pg 50 on how systems allocate blocks of memory from different size pools for efficiency and do adjustments to STL types, and then think if we've actually tuned our implementations to make the increments match these sizes.... Probably not.
• General inefficiency. While most cases were well intentioned -- see further (1) -- examples which increment by +1 are poor reflections of former array code that was switched to STL types. While it's good to see more and more the engine utilise these variable memory containers, the old array access paradigms don't always work.
• It's fine where we've done some profiling and up front do one reserve() to allocate memory and preserve cache coherency. But not when a fixed, arbitrary increment is used multiple times. There were quite a few examples of these "magic numbers" in the code.

Next post I'll go into methods to be used to profile the impact of small code changes.