[issue1518] Fast globals/builtins access (patch)

Antoine Pitrou added the comment: See issue 10401. Quoting myself: “Here is the Nth patch for a globals/builtins cache. As other caches at the same kind, it shows very small to no gain on non-micro benchmarks, showing that contrary to popular belief, globals/builtins lookup are not a major roa

[issue1518] Fast globals/builtins access (patch)

Larry Hastings added the comment: It sort of looks like this was closed because we assumed we were moving to Unladen Swallow. We're not. Should this be reopened? -- nosy: +larry ___ Python tracker ___

[issue1518] Fast globals/builtins access (patch)

Mark Lawrence added the comment: Closing as recommended in msg101239. -- nosy: +BreamoreBoy status: open -> closed ___ Python tracker ___

[issue1518] Fast globals/builtins access (patch)

Antoine Pitrou added the comment: Thanks Collin, recommend closing then. -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue1518] Fast globals/builtins access (patch)

Collin Winter added the comment: Antoine: yes, this optimization is already implemented in the Unladen JIT. -- ___ Python tracker ___

[issue1518] Fast globals/builtins access (patch)

Antoine Pitrou added the comment: There probably isn't any point in such a complication, until perhaps we have a JIT that magnifies the improvement. (but I assume the JIT will be able to treat references to globals and builtins as "frozen" using its own logic) --

[issue1518] Fast globals/builtins access (patch)

Changes by Antoine Pitrou : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue1518] Fast globals/builtins access (patch)

Changes by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue1518] Fast globals/builtins access (patch)

Changes by Collin Winter : -- nosy: +collinwinter, jyasskin type: feature request -> performance ___ Python tracker ___ ___ Python-bugs

[issue1518] Fast globals/builtins access (patch)

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Won't have time myself. -- assignee: gvanrossum -> priority: critical -> normal ___ Python tracker <[EMAIL PROTECTED]> ___

[issue1518] Fast globals/builtins access (patch)

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Ping. -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue1518] Fast globals/builtins access (patch)

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue1518] Fast globals/builtins access (patch)

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Making sure I look at this at least once carefully before releasing. -- assignee: -> gvanrossum priority: -> critical __ Tracker <[EMAIL PROTECTED]> _

[issue1518] Fast globals/builtins access (patch)

Neal Norwitz added the comment: I've gone over this at a high-level and looked for various outstanding issues. Below are my comments. I didn't delve into this in detail. There are a lot of questions too. I think this is very interesting and hope that we can get it working, 100% robust, and ve

[issue1518] Fast globals/builtins access (patch)

Changes by Gabriel Genellina: -- nosy: +gagenellina __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue1518] Fast globals/builtins access (patch)

L. Peter Deutsch added the comment: Sorry, I wrote "E's cached pointer to C.f", which of course should be "E's cached pointer to A.f". __ Tracker <[EMAIL PROTECTED]> __

[issue1518] Fast globals/builtins access (patch)

L. Peter Deutsch added the comment: The proposed approach to speeding up lookup of inherited methods is not quite sound, given that class attributes can be added and removed dynamically. Consider: class A: def f(x): ... class B(A): pass class C(B): pass If C caches a pointer to A.f, the w

[issue1518] Fast globals/builtins access (patch)

Neil Toronto added the comment: Christian: Thanks for that, I'll have to remember DEBUG_LEAK in the future. :) It looks like it may be acting correctly since there *is* now a fastglobals object that needs collecting, and also a new tuple built from co_names + "__builtins__". I don't know why it

[issue1518] Fast globals/builtins access (patch)

Changes by Guido van Rossum: -- keywords: +patch nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscr

[issue1518] Fast globals/builtins access (patch)

Chris Mellon added the comment: I may have had some old code in the build or something - I did a clean rebuild to look at some of the slowdowns and the fastglobals_test benchmarks are now even better than Neils. Pybench is still overall slower but it's mostly in float operations, which seems odd

[issue1518] Fast globals/builtins access (patch)

Chris Mellon added the comment: In funcobject.c:PyFunction_New, the declarations of op and __name__ need to be moved to the top of the function to compile in MSVC, and if accepted the fastglobals.c file needs to be added to PCBuild. In the test script, the use of import * generates syntax warnin

[issue1518] Fast globals/builtins access (patch)

Christian Heimes added the comment: When I run the code of test_gc.py test_function() in a shell I'm getting the expected result of 2 collected items: gc: collectable gc: collectable However the same code embedded in the test suite collects two additional objects: gc: collectable gc: collec