On February 22, 2006 05:59 am, Adrian Ho wrote: > On Wed, Feb 22, 2006 at 11:11:45AM +0200, Ulrich Sch?bel wrote: > > I tried your script and got, after a slight modification, quite > > consistent results. When I tried it as is, I got slightly varying > > time results with a peak in the 50 to 100 region. Then I > > commented out all lines concerning the deletion, creation > > and filling to get the pure retrieval times. Drom then on > > I got the following almost invariable results,
You probably need to consider time-slices because you are working with a multitasking operating system in which you have 1 CPU doing a little of each task so that you get multiple processes done at the same time. For example an old OS/2 warp3 running on a 40MHz 386 would slice a second into 32 partitions and allocate processes into each of those partitions. In that case, you would get timing with granularity of 1/32 of a second and might fit 4 queries in one slice and 1 query in the next available slice. You also need to take into account background tasks such as reading/writing harddrive, etc. which also skew your results, therefore if you want an idea of timing, you really should deal with large sets of runs. Even the old versions of windows timer functions were only reliable down to about 100ms slices or something like that. Later versions of operating systems expect to run on fast processors and would be waiting forever with nothing to do with only 32 multitasking slices per second, and therefore divide 1 second into far more slices, maybe 100 or 1000 slices per second, which also translates into more consistent results from your point of view. Tasks such as disk I/O are an eternity of waiting for something like a 1GHz computer. For example, this may have started on 1 time slice but had to wait for disk i/o to complete it's task in another time slice... who knows, maybe even the disk I/O caches needed to get flushed to work on the new file???: > > t(1)=538 microseconds per iteration This may have managed to complete all 5 tasks in 1 time slice, and may already have been loaded into the disk I/O cache buffers???: > > t(5)=69.2 microseconds per iteration This may have been lucky to squeeze all 10 tasks in 1 time slice: > > t(10)=39.9 microseconds per iteration No comment here because the large runs below are more consistent. > > t(50)=391.48 microseconds per iteration > > t(100)=215.61 microseconds per iteration > > t(500)=73.154 microseconds per iteration These number are more consistent because you sort of skip the problem of time slicing, disk buffers and flushing, because you deal with large runs of info. These are the types of numbers you run to get a good idea of timing: > > t(1000)=54.753 microseconds per iteration > > t(5000)=40.9094 microseconds per iteration > > t(10000)=39.4558 microseconds per iteration Hope that helps from an Operating System point of view.
