Andy Dent wrote: > 1) I put DIM in blocks to guarantee scope so I know something is > released at the end of the block, for objects. This is more often for > if/then blocks than loops. It is a more robust coding practice as it > avoids accidental use of the variable beyond a point at which it might > be valid (the compiler is your friend). > > 2) I frequently have native types with a local DIM, sometimes for > intermediate values. This is a habit from C++ programming but it > provides a lot more clues to a compiler that it can optimise that > variable into a register rather than having to do a wider analysis to > determine if a variable allocated earlier is used outside the block. > Whilst RB may not do that kind of optimisation now, it could move to > it in future and my code will automatically benefit. I admit to not > having looked at the generated assembly but I suspect there's little > overhead for having a native type with local DIM in a loop as opposed > to a DIM outside the loop and assignment of a new value within.
I was surprized by how much overhead there actually was. While it is indeed minor, given the non-optimizing compiler, it is a valid optimization. My most recent encounter with this type of code was in a very tight loop where the dims accounted for almost 10% of the cpu. Tim No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.2/781 - Release Date: 4/30/2007 9:14 AM _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
