Dean,

First, there is a finite resolution for the computer's clock (I remember something like 1/18 second). Second, the only way to truly test for 500,000 records is test against 500,000 records many thing change when the record count goes up. The code execution speed is not the only factor. There is memory consumption, swap file hits, buffer updates, etc. etc. Often, the execution time does change in direct relation to the number of records. I have had both situations, where the time was less affected by increased records than I would have assumed and others where the time was more affected by increased number of records.

My point is that the profiler is not USELESS, it serves a purpose. It helps to find specifically poor performing lines of code. It really helps in finding those 17 calls to the refresh that we passed over. It shows the code lines in a larger loop that are real hogs.

When it comes to tweaking the nanoseconds out of data processing code, well you have to test against actual record counts as much as possible. When you can't do that, then the tests are a best a quess as to how it will work.