Mailman 3 July 2011 - pypy-issue

[issue644] Add option parser to package.py
by Dan 09 May '14

09 May '14

New submission from Dan <dcolish(a)gmail.com>: I've been using package.py a lot more often now and I find an option parser interface to be nice for command line scripts. I've written one for package.py, but I believe it will require buildbot updates since buildbot is calling the old interface. ---------- effort: ??? files: package.diff messages: 2169 nosy: dcolish, pypy-issue priority: wish release: ??? status: in-progress title: Add option parser to package.py _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue644> _______________________________________________________

2 1

[issue662] get_config_vars has nothing for CC, while expected internally
by Martijn 08 May '14

08 May '14

New submission from Martijn <ss(a)kleptog.org>: Currently distutils.sysconfig.get_config_vars() has no value for CC. This means that when you try to build a C extension using distutils it breaks, because distutils internally uses get_config_vars() to determine the compiler (distutils/ccompiler.py). Attached is a patch that works for me, with this C extensions build normally (excluding cpyext problems). But this may be a layering violation, so I'll leave it to you guys to determine the correct fix. In any case it's an improvement which improves compatibility. ---------- effort: ??? files: distutils.patch messages: 2267 nosy: kleptog, pypy-issue priority: feature release: ??? status: unread title: get_config_vars has nothing for CC, while expected internally _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue662> _______________________________________________________

4 3

[issue733] bz2 decompression is very slow
by Jonas H. 23 Apr '14

23 Apr '14

New submission from Jonas H. <jonas(a)lophus.org>: Compared to CPython 2.7, PyPy 1.5 (from the Arch Linux repositories) seems to be ~5 times slower on bz2 decompression. Using this script: from bz2 import BZ2File with BZ2File(sys.argv[1]) as f: while True: if not f.read(8*1024): break to decompress the PyPy lib-python/ directory (60M compressed) takes about 5 seconds on CPython and 20s on PyPy 1.5. ---------- messages: 2569 nosy: jonash, pypy-issue priority: bug release: 1.5 status: unread title: bz2 decompression is very slow ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue733> ________________________________________

5 10

[issue805] 64 bit 30% slower than 32bit pypy
by Fijal 23 Apr '14

23 Apr '14

New submission from Fijal <fijall(a)gmail.com>: Attached example (regexes) ---------- messages: 2841 nosy: fijal, pypy-issue priority: bug status: unread title: 64 bit 30% slower than 32bit pypy ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue805> ________________________________________

2 1

[issue718] string.plit('\x00') takes 300% longer under pypy1.5 w/jit
by Robert Collins 23 Apr '14

23 Apr '14

New submission from Robert Collins <robertc(a)robertcollins.net>: under cpython: 11:37 < lifeless> 3 0.000 0.000 0.280 0.093 journals.py:678(_tokens) under pypy(1.5, 64-bit build, your official download) 11:38 < lifeless> 3 0.000 0.000 1.161 0.387 journals.py:678(_tokens) _tokens is defined as def _tokens(): return content.split('\x00') content in the timed case is a 74MB bytestring consisting of \x00 separated fields; the fields are highly redundant - for example one in 5 in the case that produced this is 'add', another one in 5 is 'file', and the rest are 'dir', 'symlink' and relative paths, and floats (as ascii). There are 3331176 fields (len(content.split('\x00'))==3331176) ---------- effort: ??? messages: 2507 nosy: lifeless, pypy-issue priority: bug release: ??? status: unread title: string.plit('\x00') takes 300% longer under pypy1.5 w/jit _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue718> _______________________________________________________

3 2

[issue782] Order of calls changes performance
by Ismael 23 Apr '14

23 Apr '14

New submission from Ismael <ismaelgfk(a)gmail.com>: In the following code, the order of calls alters the performance. First case: running calc first, then calc_arr second: ismael@chaos:~/Escritorio$ ~/pypy/bin/pypy slow.py Section time: 0.865699052811 -- Calc Section time: 0.757493019104 -- Calc_arr So, here, best time for calc_arr is 0.75s. It doesn't matter if I run it 10 times, it still about that fast. Now, running calc_arr first and calc second: ismael@chaos:~/Escritorio$ ~/pypy/bin/pypy slow.py Section time: 0.400774002075 -- Calc_arr Section time: 1.53682088852 -- Calc The method that took 0.7s now takes 0.4! And the one that took 0.8s now takes 1.5! For comparison, PyPy latest (45351) is even worse: ismael@chaos:~/Escritorio$ ~/pypy/pypylatest/pypy-c-jit-45351-2630c86662b4-linux64/bin/pypy slow.py Section time: 0.940190792084 -- Calc Section time: 0.925091981888 -- Calc_arr ismael@chaos:~/Escritorio$ ~/pypy/pypylatest/pypy-c-jit-45351-2630c86662b4-linux64/bin/pypy slow.py Section time: 0.418694019318 -- Calc_arr Section time: 1.73908495903 -- Calc Code modified from http://technicaldiscovery.blogspot.com/2011/07/speeding-up-python-again.html class Timer(object): def __enter__(self): self.start = time.time() def __exit__(self, exc_type, exc_val, tb): print "Section time: ", time.time() - self.start import array import time dx = 0.1 dy = 0.1 dx2 = dx*dx dy2 = dy*dy def py_update(u,nx,ny): for i in xrange(1,nx-1): for j in xrange(1, ny-1): u[i][j] = ((u[i+1][j] + u[i-1][j]) * dy2 + (u[i][j+1] + u[i][j-1]) * dx2) / (2*(dx2+dy2)) def calc(N, Niter=100): u = [[0.0]*N for i in xrange(N)] for i in xrange(N): u[0][i] = 1.0 for i in range(Niter): py_update(u,N,N) return u def calc_arr(N, Niter=100): u = [array.array("d", [0.0])*N for i in xrange(N)] for i in xrange(N): u[0][i] = 1.0 for i in range(Niter): py_update(u,N,N) return u #Compare this: with Timer(): u = calc_arr(150,1000) with Timer(): u = calc(150,1000) #To this (comment the previous section): with Timer(): u = calc(150,1000) with Timer(): u = calc_arr(150,1000) ---------- messages: 2741 nosy: Ismael, pypy-issue priority: bug release: 1.5 status: unread title: Order of calls changes performance ________________________________________ PyPy bug tracker <tracker(a)bugs.pypy.org> <https://bugs.pypy.org/issue782> ________________________________________

4 5

[issue670] on translate.py we get very long chains of PlainAttribute.index
by Fijal 23 Apr '14

23 Apr '14

New submission from Fijal <fijall(a)gmail.com>: Identified on OS X, unsure about linux but seems very likely. Also they end up with stackcheck that somehow exits, but we seem to catch the error and go on. ---------- effort: ??? messages: 2292 nosy: pypy-issue priority: bug release: ??? status: unread title: on translate.py we get very long chains of PlainAttribute.index _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue670> _______________________________________________________

2 1

[issue517] `_ast` make `lineno` and `col_offset` optional
by Pavel Panchekha 23 Apr '14

23 Apr '14

New submission from Pavel Panchekha <pavpanchekha(a)gmail.com>: The `_ast` module in pypy currently forces the user to specify the `lineno` and `col_offset` fields when constructing any of the AST objects that have them. For better conformance to CPython 2.6's behavior, these two attributes should be optional, and when they are not provided, should not be set. ---------- effort: easy messages: 1683 nosy: hpk, pavpanchekha, pypy-issue priority: wish release: ??? status: unread title: `_ast` make `lineno` and `col_offset` optional _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue517> _______________________________________________________

2 1

[issue640] Possible optimization in FOR_ITER on a constant tuple
by Alex Gaynor 23 Apr '14

23 Apr '14

New submission from Alex Gaynor <alex.gaynor(a)gmail.com>: Given: for x in (1, 2, 3): i += x We currently generate: FOR_ITER to 47 guard(i5 is 1) guard(guard_class(p7, 146344448)) p14 = ((pypy.objspace.std.iterobject.W_FastTupleIterObject)p7).inst_tupleitems guard(guard_nonnull(p14)) i15 = ((pypy.objspace.std.iterobject.W_AbstractSeqIterObject)p7).inst_index i16 = arraylen_gc(p14) i17 = i15 >= i16 guard(i17 is false) p18 = getarrayitem_gc(p14, i15) i20 = i15 + 1 This is slightly inefficient in a few places, the getitem, for tupleitems, could be eliminated, as could the arraylen. ---------- effort: ??? messages: 2155 nosy: agaynor, pypy-issue priority: wish release: ??? status: unread title: Possible optimization in FOR_ITER on a constant tuple _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue640> _______________________________________________________

2 1

[issue593] ctypes.Array performance issues
by David Naylor 23 Apr '14

23 Apr '14

New submission from David Naylor <naylor.b.david(a)gmail.com>: ctypes.Array performance in PyPy is substantially slower than CPython. A profile shows that PyPy's Array assigns each item of the array, which is rather slow. The following (reduced) code shows the problem: # cat ctype-array.py from multiprocessing import Array from time import time data = " " * (1024 * 1024 * 10) # 10MiB start = time() array = Array('c', data, lock=False) print "%fs" % (time() - start) # python ctypes-array.py 4.234547s # pypy-fast-forward ctypes-array.py 32.414674s which shows an approximate 7.5x increase in execution time, against PyPy. ---------- effort: ??? messages: 1933 nosy: DragonSA, pypy-issue priority: bug release: ??? status: unread title: ctypes.Array performance issues _______________________________________________________ PyPy development tracker <pypy-dev-issue(a)codespeak.net> <https://codespeak.net/issue/pypy-dev/issue593> _______________________________________________________

2 1