.readline() - VERY SLOW compared to PERL

Harald Schneider h_schneider at marketmix.com
Fri Nov 17 02:30:04 EST 2000


That's right - no good tradeoff. Hope that further releases will optimize
that issue.
Thanks !

All the best,
Harald


"Erno Kuusela" <erno-news at erno.iki.fi> schrieb im Newsbeitrag
news:kulmujir4v.fsf at lasipalatsi.fi...
>
> i did some quick testing on my linux machine, namely changed getc to
> getc_unlocked:
>
> % ./python /tmp/test.py /usr/share/unidata/UnicodeData-2.1.8.txt
> 0.21 s
> % python2.0 /tmp/test.py /usr/share/unidata/UnicodeData-2.1.8.txt
> 1.65 s
>
> the first one is the modied version, and the second one is
> vanilla. the file is 6890 lines long. my cpu is a k6/200.
>
> for reference, a loop over open(f).readlines() takes 0.16 secs.
>
> here is the test program:
>
> import sys, time, operator
>
> def test_read(f):
>         n = 0
>         next = open(f).readline
>         while 1:
>                 l = next()
>                 if not l: break
>                 n = len(l) + n
>         return n
>
> def main():
>         import time
>         r = []
>         for i in range(3):
>                 start = time.time()
>                 test_read(sys.argv[1])
>                 r.append(time.time() - start)
>         print '%.2f s' % (reduce(operator.add, r) / len(r))
>
> main()
>
> of course, it is not so simple, because the getc is inside a
> Py_BEGIN_ALLOW_THREADS block so just removing the locking
> could make things go haywire.
>
> but slowing down all file accesses by a factor of ~8 for
> the sake of concurrent readline()s on the same file object
> from different threads doesn't seem like a very good tradeoff
> for me.
>
>
>   -- erno
>





More information about the Python-list mailing list