list.sort(func) speed

Michael Peuser mpeuser at web.de
Sun Aug 31 12:24:49 CEST 2003


"Peter Otten" <__peter__ at web.de> schrieb im Newsbeitrag
news:bisf20$na3$01$1 at news.t-online.com...
> Michael Peuser wrote:
>
> > It drove me nearly crazy when I detected that os.path split and join
> > operations took even longer than raw disk access in a directory scan
> > program....
>
> Now, that was a fast disk :-) I fear, that some data was already in the
> cache when your improved version was executed. Please post some sample
> code/timings for the unbelieving.

I did some weeks ago: news:bhd9vg$1s7$05$1 at news.t-online.com...

>
> > Please note that all os.path functions are *awfully* slow! If ever
> > possible use a nonportable self made scheme.
>
> If ever possible, use a *portable* scheme shipped with the distribution.
> Chances are that it is ahead of your ad hoc solution in terms of
> correctness. If you have written code that greatly improves on the current
> implementations, you might consider submitting a patch...

I am definitly on your side what general portability is concerned. However
the format of file names is quite well defined and had not changed in
Windows Unix and MacOs for a long time ;-)

It depends of course on your clients and they generally work with Windows
and are happy when you say it *could* run on Unix. (I am a little bit
unhappy about the situation in this NG, where a lot of posters are not aware
of expectations, requirements and needs of Windows users. There *is*
competition in the Windows market!)

>
> > (The other issue (decorated sorting) is more relevent of course.)
> D'accord. Namely, basename() is not the bottleneck here.

Of course not - this was a side isssue. Reducing a factor of a quadratic
problem is generally better than a linear speed-up. Though it depends on the
order of magnitude ;-)

Kindly
Michael P






More information about the Python-list mailing list