On May 1, 2007, at 12:40 AM, Tim Hare wrote: > 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.
This is interesting. I had tested this early on and didn't find any measurable difference. In response to your message, I tested it again, and found that there was a significant difference, but only in Mac OS Intel builds. In Mac OS PPC builds, there doesn't appear to be any difference in performance. Charles Yeomans _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
