Surprising (for me) benchmark results...

[Daniel Berlin]

On Wed, 2 May 2001, Rainer Deyke wrote:

> "Daniel Berlin" <dan at www.cgsoftware.com> wrote in message
> news:mailman.988762570.8591.python-list at python.org...
> > Actually, the sort is probably not the bottleneck.
> > As the file gets larger, the bottleneck becomes disk time, not sort time.
>
> Disk access is O(N);

Out of where did you pull this?

It's non-determinstic, practically, because it depends on way too many
factors (where the disk is, your memory subsystem, your processor usage,
your DMA capabilities, etc). It also depends where on the disk the
file is, if it's entirely contiguous, etc.

> sorting is typically O(N log N).
> Therefore as the
> number of entries in the file size increases, the time taken by the sort
> becomes more significant and the time taken by disk access becomes less
> significant.
Bullshit.  Please back this up with facts, not hand waving.
Disk transfers are 7-16 meg per second, sustained, plus seek time.
(Obviously the internal disk transfer rate is *much* higher)
When the total program time is 600-1400ms, and you are including the disk
i/o time, it's fair to assume a large portion of it could be disk I/O
time.

>  This  is assuming that  the file fits into memory (as was the
> case here).
You still have to read it in. What really needs to be done is to time the
*sort*, not the entire program.

>
>
> --
> Rainer Deyke (root at rainerdeyke.com)
> Shareware computer games           -           http://rainerdeyke.com
> "In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>