Wasn't this discussed on Python-Dev recently? I think CPython has the same problem. Cheers, Ben pypy-svn-bounces@codespeak.net wrote on 26/08/2005 12:07:00: pypy/dist/lib-python/2.4.1/linecache.py
Hi Ben, On Fri, Aug 26, 2005 at 12:10:35PM +0100, Ben.Young@risk.sungard.com wrote:
Wasn't this discussed on Python-Dev recently? I think CPython has the same problem.
I can't tell. I would be surprized if the problem is exactly the same: it seems that (at that point) if we replace f.readlines() with f.read().splitlines(True), things are seriously faster. This points to a problem in our lib/_sio.py which is exposed by our lib/_file.py. Meanwhile, Richard removed this linecache.py hack after he figured out one thing that killed performance: string slicing. Its implementation in stringobject.py was very old and completely broken performance-wise. A bientot, Armin
Hi Ben, On Fri, Aug 26, 2005 at 12:10:35PM +0100, Ben.Young@risk.sungard.com wrote:
Wasn't this discussed on Python-Dev recently? I think CPython has the same problem.
I can't tell. I would be surprized if the problem is exactly the same: it seems that (at that point) if we replace f.readlines() with f.read().splitlines(True), things are seriously faster. This points to a problem in our lib/_sio.py which is exposed by our lib/_file.py. Meanwhile, Richard removed this linecache.py hack after he figured out one thing that killed performance: string slicing. Its implementation in stringobject.py was very old and completely broken performance-wise. A bientot, Armin
participants (2)
-
Armin Rigo -
Ben.Young＠risk.sungard.com