Hello, Just out of interest (I haven't investigated yet), py.py loads in Python 2.4a3 but 'import dis' apparently sends it into an infinite loop. It also prints 'faking <type 'module'>' just after 'import dis', which it doesn't do with Python 2.3.3. Funny. Armin
Hi, On Mon, Sep 27, 2004 at 08:25:41PM +0100, Armin Rigo wrote:
This is due to opcode.py, which in 2.4 uses string formatting to build opcode names, while in 2.3 it uses concatenation. From the diff: < for op in range(256): opname[op] = '<' + `op` + '>' ---
for op in range(256): opname[op] = '<%r>' % (op,)
As it happens, string formatting is *really* *slow* in PyPy now. Every one takes about 1 second! So importing opcode.py takes several minutes. Quoting Michael, "time to make string formatting faster". Armin
hpk@trillke.net (holger krekel) writes:
Or work out why it's so painfully slow currently, via hotshot or whatever. One could create a half-assed interpreter level implementation by just executing the current code at interpreter level (and probably changing a few little things, like calling space.str instead of str). It almost certainly wouldn't be RPython though (esp. the floating point stuff which uses long arithmetic; the rest might be close). Not a lot of fun, though. Cheers, mwh -- Important data should not be entrusted to Pinstripe, as it may eat it and make loud belching noises. -- from the announcement of the beta of "Pinstripe" aka. Redhat 7.0
Hi, On Mon, Sep 27, 2004 at 08:25:41PM +0100, Armin Rigo wrote:
This is due to opcode.py, which in 2.4 uses string formatting to build opcode names, while in 2.3 it uses concatenation. From the diff: < for op in range(256): opname[op] = '<' + `op` + '>' ---
for op in range(256): opname[op] = '<%r>' % (op,)
As it happens, string formatting is *really* *slow* in PyPy now. Every one takes about 1 second! So importing opcode.py takes several minutes. Quoting Michael, "time to make string formatting faster". Armin
hpk@trillke.net (holger krekel) writes:
Or work out why it's so painfully slow currently, via hotshot or whatever. One could create a half-assed interpreter level implementation by just executing the current code at interpreter level (and probably changing a few little things, like calling space.str instead of str). It almost certainly wouldn't be RPython though (esp. the floating point stuff which uses long arithmetic; the rest might be close). Not a lot of fun, though. Cheers, mwh -- Important data should not be entrusted to Pinstripe, as it may eat it and make loud belching noises. -- from the announcement of the beta of "Pinstripe" aka. Redhat 7.0
participants (3)
-
Armin Rigo -
hpk＠trillke.net -
Michael Hudson