Hi Team,
I am running ETIME on a progress .p, I am passing in the same input and the output is also the same, but each time i get different execution time. Why we are not getting a constant time for the execution of the specific program. Is there any other ways to findout the exact execution time of a program constantly ?
Regards,
Ramalingam.V
"Execution time" depends on several factors like the OS, free memory, CPU usage etc. So, you get different values for each execution.
One of the best practices is to calculate average of few execution times.
Most dramatically, if the thing you are testing includes some data fetches, the first time you run it the data may have to be fetched from disk, but if you run it again without restarting the server, the data will be in the buffer. BIG DIFFERENCE!
Hi Thomas,
Please shade some more light on the DB Cache. How it works and is there any documentation to understand it
Regards,
Ramalingam.V
Further explorations are best conducted in the RDBMS forum, but briefly the -B parameter establishes a cache for the DB. If a record is to be read, it looks first in the cache. It may be found there because it was recently read or simply because it is in a block which was recently read. When reading lots of records from a table with a small record size and large blocks, one may get quite a few reads "for free" even if none of the blocks was in memory before the operation started. Of course, rereading the same set of records any time soon is likely to boost performance significantly since the blocks containing the records are likely to still be in the cache. With a well tuned database, i.e., a large enough -B, it is not uncommon and in fact expected that 98+% of all reads will come from the -B cache. But, if one is reading a set of records for the first time after a boot, i.e., when there is nothing in the cache and the record size of those records is large, then the first time one is doing a significant number of physical disk reads. The second time, maybe none. Disk reads are a couple orders of magnitude slower than cache reads.