Article # 589, added by Geoworks, historical record
| first | previous | index | next | last |

General guide for optimizing your GEOS code.




Here's some general issues to consider for optimizing your application:
for speed and memory usage:

* Don't keep blocks locked longer than necessary as it fragments the
  memory and causes the memory manager grief.  (If you are in a loop 
  or something that frequently accesses a block, do keep the block 
  locked since frequent lock/unlock takes up unnecessary CPU cycles.)

* Make sure to always use movable blocks; HF_FIXED blocks are always 
  bad because they permanently fragment the fixed heap space.

* Static variables are stored in dgroup.  dgroup doesn't move, so 
  pointers to data in dgroup can be maintained without the need to
  lock/dereference.  The trade-off is that dgrup is a HF_FIXED block,
  which will cause problems as mentioned above.

* When possible, use ChunkArrays rather than HugeArrays. While huge
  arrays allow arrays to be larger than 64K, they do so thru a level
  of abstraction that requires more computing to access an item in the
  array. Same is true of DB items.

* When performing visual updates, DO NOT use VUM_NOW.  Instead use
  VUM_DELAYED_VIA_APP_QUEUE. This will allow all the updates to occur
  simultaneously, which prevents the surge of redundent UI calculations
  cause by multiple updates using VUM_NOW.

* Processing a message call takes a mimimum of 3 times as long as a
  routine call, so use routines in loops or other parts of code that
  require speed efficiency.

* Code that must run quickly can be run by a seperate thread with the
  ThreadPriority set appropriately (something higher than PRIORITY_FOCUS).

* When using graphics, gstrings are generally faster than bitmaps for
  images that are comprised mostly of geometric shapes. For drawing
  bitmaps GrFillBitmap() is faster than GrDrawBitmap(), but the bitmap
  is drawn monochrome.

* Borland compiler optimizations. These flags will tell Borland C to
  optimize compilation for speed/size.  Set these flags with the
  CCOMFLAGS flag in your local.mk file. CAVEAT:  We Have Not Tested
  All These Flags and cannot guarantee that Borland will generate
  correct code when these flags are used.

 -O1 size optimization 
 -b- Allocate enums as ints [default: off] (makes enums byte-size when
     possible)
 -Z Suppress redundant loads 
 -Oc Optimize locally
 -Og Optimize globally
 -Ob Dead-code elimination
 -Oe Global register allocation (required for -Ob) 
 -O Jump optimizations
 -Ol Loop optimization
 -Op Copy propagation (improves performance, and doesn't increase code size)

  The following flags all yielded good size reductions:
        -Z -Os -O
  Minor gains were seen with:
        -Ol -d