[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Changes by Yury Selivanov : -- superseder: -> Speedup method calls 1.2x ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

R. David Murray added the comment: Benjamin confirms a regression in his patch, and the other patch was not intended for CPython. So I'm closing this issue. -- nosy: +r.david.murray stage: patch review -> committed/rejected status: open -> closed __

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Reid Kleckner added the comment: Sorry, I was just posting it so Benjamin could see what this bought us. I'm not pushing to get this in CPython. The results are for JITed code. I forget what the interpreted results are. I think they are good for the microbenchmarks, but not as good for the

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Changes by Antoine Pitrou : -- stage: -> patch review versions: -Python 2.7 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Antoine Pitrou added the comment: First, are these benchmark results jitted or non-jitted? Right now, non-jitted results are a stronger motivation for inclusion in main CPython, IMHO. Second, 2.7 won't receive any features / performance improvements anymore. It would be nice to have 3.2 (non

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Reid Kleckner added the comment: I have an patch for unladen-swallow out for review here: http://codereview.appspot.com/160063/show It resolves the correctness issues I mentioned previously by emitting guards if necessary. If the type is predictable and uses slots, then we don't need to chec

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Benjamin Peterson added the comment: Yes, my patch introduces that regression you mention. PyPy solves this by having the instances dictionary keep track of shadowing of the type dictionary. Not easy for CPython... I wish you luck on your patch! -- _

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Reid Kleckner added the comment: One thing I was wondering about the current patch is what about objects that have attributes that shadow methods? For example: class C(object): def foo(self): return 1 c = c() print c.foo() c.foo = lambda: 2 print c.foo() Shouldn't the above print

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Changes by Reid Kleckner : -- nosy: +rnk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Antoine Pitrou added the comment: Similar results here. With the patch: Richards benchmark (Python) starting... [] finished. Total time for 4 iterations: 1.78 secs Average time per iteration: 443.90 ms Without the patch: Richards benchmark (Python) starting... [] finished. Total time for 4 it

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Benjamin Peterson added the comment: With the patch: Richards benchmark (Python) starting... [] finished. Total time for 10 iterations: 8.49 secs Average time per iteration: 848.90 ms Without: Richards benchmark (Python) starting... [] finished. Total time for 10 iterations: 10.46 secs Averag

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Antoine Pitrou added the comment: Can you give results of the "richards" benchmark? -- nosy: +pitrou ___ Python tracker ___ ___ Python

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

New submission from Benjamin Peterson : This is an optimization ported from PyPy. [1] It tries to prevent bound methods from being created by using the stack as a cache. I couldn't apply this to builtin methods because those use a method-wrapper descriptor. The results were not very impressive. H