Optimizing your Application

for speed and heap usage

The following are some points to consider for optimizing your Geos application.

• 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 as freqent lock/unlock takes up unecessary CPU cycles. Make sure to always use movable blocks; HF_FIXED blocks are always bad because they 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 need to lock/dereference. The trade-off is that a large dgroup is more likely to cause memory fragmentation and thus give grief to the memory manager.
• 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, use VUM_DELAYED_VIA_APP_QUEUE. This will allow all the updates to occur simultaneously thus preventing redundent UI calculations.
• 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). (see special informaiton about ThreadCreate() that is at the end of this email.)
• 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. I.E., we cannot guarantee that Borland will still generate correct code, when these flags are used. Now then, to the flags:

  -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

Whitepapers

Last modified: Thu Jan 8 10:34:16 PST

r*bettsteller#web*de ---- If you are not a robot replace * by . (dot) and # by @
Wenn Sie kein Roboter sind ersetzen Sie * durch . (Punkt) und # durch @ (Klammeraffe)
Datenschutzerklärung | Haftungsausschluss | Impressum | Privacy Policy (English) | Disclaimer (English)