[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Martin v. Löwis added the comment: > Returning the same object vs new object for bound methods is a > non-guaranteed implementation detail (as long the other semantics remain > true). I think Martin's real concern is that trying to intern bound > methods would be a can of worms (one that I wou

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Raymond Hettinger added the comment: [AP] > Does this optimization actually help in real-world cases? Yes and no. Yes, there are real world cases like ','.join and '{}'.format that are dramatically sped-up. No, there are probably no real-world programs that are sped-up significantly in their

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Raymond Hettinger added the comment: Returning the same object vs new object for bound methods is a non-guaranteed implementation detail (as long the other semantics remain true). I think Martin's real concern is that trying to intern bound methods would be a can of worms (one that I wouldn't

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Antoine Pitrou added the comment: Does this optimization actually help in real-world cases? -- nosy: +pitrou ___ Python tracker ___ __

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Collin Winter added the comment: On Fri, May 29, 2009 at 3:45 PM, Martin v. Löwis wrote: > py> s = "" > py> s.join is s.join > False > > Every time you read it, you get a new object. Not what I would call a > constant. If you don't see how this matters, try > > def foo(): >  return "".join > >

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Terry J. Reedy added the comment: You are right, of course: bound methods are currently created fresh on each access, even though each is equal except for identity. I was thinking in terms of >>> str.join is str.join True This appears to be a classic time-space tradeoff: caching bound methods

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Martin v. Löwis added the comment: Terry J. Reedy wrote: > Terry J. Reedy added the comment: > > Martin, I agree that we would have to think carefully about all > attributes of all constants loaded by LOAD_CONST, and about > special-casing marshal, but given that "'str' object attribute 'join'

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Raymond Hettinger added the comment: Attaching a rough patch for caching constant attribute lookups. Has an open TODO for adding the new name to co->co_varnames. -- Added file: http://bugs.python.org/file14115/constattr.diff ___ Python tracker

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Raymond Hettinger added the comment: I'm working a better patch now. Will give to collin to review when it's ready. Here's a draft of the new opcode: TARGET(LOAD_CONST_ATTR) u = GETLOCAL(oparg);/* Cached attribute or NULL */

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Terry J. Reedy added the comment: Martin, I agree that we would have to think carefully about all attributes of all constants loaded by LOAD_CONST, and about special-casing marshal, but given that "'str' object attribute 'join' is read-only", how is ''.join not a constant? Do you have another e

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Changes by Collin Winter : -- nosy: +collinwinter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Alex added the comment: Fully functional. -- Added file: http://bugs.python.org/file14106/python_const_fold.diff ___ Python tracker ___ __

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Raymond Hettinger added the comment: I would like to see the current patch finished and recorded here for reference. But I agree with Martin that changing marshal is a can of worms. The peepholer is intended to be conservative and should avoid anything that has some risk of being complicating

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Martin v. Löwis added the comment: -1. const.attr is not necessarily a constant. Indeed, "".join is *not* a constant. Furthermore, using this approach will lead to an endless series of types to be added to marshalling, which is bad. For example, I believe that current patch breaks on "".__class

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Alex added the comment: Optimization now works in the shell fine, and marshal.loads(marshal.dumps(''.join)) works fine in the shell. However when I try to run the tests the import of collections.namedtuple causes the ValueError bad marshal data to appear, and I don't know why. Could it have to

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Alex added the comment: I now *almost* have PyCFunctions marshalling, they seem to marhshall ok but fail on unmarshalling. I think the whitespace stuff may have crept back in, sorry :( -- Added file: http://bugs.python.org/file14101/python_const_fold.diff _

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Alex added the comment: Switch to using memset instead of a forloop. -- Added file: http://bugs.python.org/file14100/python_const_fold.diff ___ Python tracker ___ ___

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Alex added the comment: Small update so I don't change whitespace all over the plcae. -- Added file: http://bugs.python.org/file14099/python_const_fold.diff ___ Python tracker __

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

Alex added the comment: Here's my work so far, it seems to work as described. Except for the fact that pyc creation with anything containign something with this optimization will give a valueerror on bad marshall data, from trying to marshall the method I assume. -- keywords: +patch Ad

[issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to just be a LOAD_COST

New submission from Alex : Basically whenever you have a LOAD_CONST opcode, follwed by a LOAD_ATTR you can replace both with a single LOAD_CONST. This optimizes things like ", ".join or "{} {}".format (in my totally unscientific byte code hackery it's about a 30% speedup on the loading the funct