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