Hi Kevin

>Individual times for first-time load can vary greatly, for a variety of apps.
Yupp, I realize that and also some of the reasons - just some sloppy formulating by me.

"First Start" times (best done from cold boot) should be reported as such and "other starts" as well. Even if the developer realizes/acknowledges the start time spent with loading the framework, grabbing a hunk of memory and jitting this doesn't mean the client will approve - even if clients are getting habituated by the start time of MS Office Applications. (I have a few old programs on my disk just for kicks: Starting Excel 2.0 is quite fast on old HW <bg>)

Still, having an idea of the range of start times allows me to adress this issue up front:
if fast starts really are a must, this should enter the specs and my calculation <bg>.

>Not saying that these reported times aren't important,
>but there can be so many factors on a machine.
Agreed, but sometimes the application needs to be fast even in the first time.
Even if that is not really the case, customer's ***wishes*** are the reason
for him to contract me to develop an app. So I'ld rather have a clear "meeting of minds",
including rudimetary description of hardware in the contract and/or test environments to be supplied to me by my customer.

So usually basic perf range is discussed up front. If I haven't miscalculated my total efforts I usually tweak the program during testing to be measurably faster than what was previously agreed.

Basic tweaks are fun, keep you on your toes against blunder [for the next job] and give you VERY satisfied customers. But you have to have some numbers...

regards

thomas