> pystone is a mystery. It's a fair bit slower but also much more > variable with my patch. Moving trace code out of line helps quite a > bit but it's still ~1% slower. Hm. For me (with your latest patch which moves the trace code out of line) pystone is actually *less* variable with your patch than without, and it's also faster with -O than before. So I wouldn't lose any sleep over pystone (leave that to Tim :-). Maybe you should increase LOOPS in pystone.py; I usually set it to 40K or even 100K. > I think I'd like to wait for serious review. I'd be surprised if the > patch went out of date at all quickly. Fair enough. > Also, it seems Lib/compiler currently works by generating SET_LINENO > and then builds co_lnotab by scanning for them afterwards. That's not > going to work in the new world, so I should probably think about how > to change it... Or wait for Jeremy. (I suppose you still *support* the SET_LINENO opcode?) BTW, you should change the .pyc magic number in your patch. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4