On Mon, Feb 03, 2003 at 11:17:11AM -0800, Neil Schemenauer wrote: > Guido van Rossum wrote: > > I'm in. Given how low you set your stakes, I don't think you're very > > confident, so I'd like to call your bluff. :-) > > Any opinion on where to spend effort? I was thinking of dusting off the > register VM code (aka rattlesnake). OTOH, perhaps the non-local > namespace optimizations would give more bang for the buck. As Guido mentioned, inline builtins. I have a real simple patch which does this. ie, LOAD_GLOBAL(name) -> LOAD_CONST(builtin_function). However, there is a problem with the patch: the resulting code can't be marshalled properly. I haven't tried to fix that yet. Right now JUMP_IF_(TRUE, FALSE) keep their computed value on the stack. They are always followed by POP_TOP. If the JUMP_IF_* removed the value, it would be one less trip through eval_frame loop (no POP_TOP). I've got a patch for this which fixes 5 of the 8 cases where JUMP_IF_* are generated. The problem with the remaining 3 cases is that a jump to a jump occurs. By removing the jump to a jump, that should also help performance. I have a crazy idea that removing the switch and making our own jump table in the eval_frame loop could improve performance. But I've never tried this because it's a lot of work. And it could hurt, not help performance. I can mail or post the partial patches if anyone is interested. Neal
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