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
- 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
- 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
- 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:
Last modified: Thu Jan 8 10:34:16 PST