[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Okay, thanks. We may do one of the other ideas (maybe co_flags & CO_DOCSTRING). -- ___ Python tracker ___ _

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: Although I still feel reducing 16% tuples is attractive, no one support the idea. I leave this as-is for now, and will go to lazy-loading docstring (maybe, co_linetable too) later. -- resolution: -> rejected stage: patch review -> resolved status: ope

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: Lazy filling func.__doc__ has only 3~5% performance gain. And it has small backward incompatibility. ``` >>> def foo(): "foo" ... >>> def bar(): "bar" ... >>> bar.__code__ = foo.__code__ >>> bar.__doc__ 'foo' # was 'bar' ``` Note that non-constant docstring (

[issue36521] Consider removing docstrings from co_consts in code objects

Change by Inada Naoki : -- pull_requests: +27065 pull_request: https://github.com/python/cpython/pull/28704 ___ Python tracker ___ _

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > Do you have any explanation of this? I think its because current PyFunction_New tries to get docstring always. See this pull request (lazy-func-doc). https://github.com/python/cpython/pull/28704 lazy-func-doc is faster than co-docstring and remove-docstring i

[issue36521] Consider removing docstrings from co_consts in code objects

Serhiy Storchaka added the comment: Hint: you can specify several arguments for multiline code. E.g. timeit -s "setup1" -s "setup2" "test1" "test2". > And as a bonus, creating function without docstring is little faster. Do you have any explanation of this? -- _

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > So overhead is around 2%. And this 2% is problem only for "creating function > with annotation, without docstring, never called, in loop" situation. My bad, "creating function with docstring, without annotation, nevercalled in loop" situation. -- __

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: And as a bonus, creating function without docstring is little faster. ``` $ cpython/release/bin/pyperf timeit --duplicate=100 "def f(): pass" . Mean +- std dev: 62.5 ns +- 1.2 ns $ load-none-remove-docstring/release/bin/pyperf timeit --duplic

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > The difference 5.1 ns is the cost of additional LOAD_CONST. It is around 8% > (but can be 12% or 2%). The cost of setting docstring externally will be the > same. I don't have bare metal machine for now so I don't know why annotation is so slow. But cost of

[issue36521] Consider removing docstrings from co_consts in code objects

Serhiy Storchaka added the comment: > I'm confused by your phrase "take data" -- do you mean remove these? Or wht > do you propose we do with them? I thought that function's name and qualname are set in the code that creates a function instead of copying from the code object. Similarly as wh

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Serhiy: > I propose an opposite change -- take data known at compile time (name, > qualname and annotations). I'm confused by your phrase "take data" -- do you mean remove these? Or wht do you propose we do with them? > It will make the code for creating

[issue36521] Consider removing docstrings from co_consts in code objects

Serhiy Storchaka added the comment: I propose an opposite change -- take data known at compile time (name, qualname and annotations). It will make the code for creating new function smaller and faster. It is what we want to achieve -- reducing import time, but additionally it will reduce tim

[issue36521] Consider removing docstrings from co_consts in code objects

Irit Katriel added the comment: > This not saves only memory usage, but also import time too. Do you see a measurable impact on import time? With LOAD_NONE I saw speedup of 8% on micro benchmarks but it didn’t make any difference overall. -- ___ P

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > For the sqlalchemy example: the saving in co_consts is about 1.6k (200 > pointers), but an increase in bytecode size of 2.4k. Please see number of co_constatns tuples. (d) saved 1307 tuples compared to (b). `sys.getsizeof(())` is 40 on 64bit machine. So 1307 tu

[issue36521] Consider removing docstrings from co_consts in code objects

Irit Katriel added the comment: It’s not clear that LOAD_NONE/LOAD_COMMON_CONST are worth doing. Any way the docstring question is not necessarily related to that. -- ___ Python tracker _

[issue36521] Consider removing docstrings from co_consts in code objects

Mark Shannon added the comment: Since the docstring itself will always be present (attached to the function object), removing a docstring from a co_consts tuple will only save one pointer (8 bytes). Given that, it would appear that (d) uses *more* memory than (b). For the sqlalchemy example

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: My machine at the office (used for benchmarking) is hanged up and I need to go to the office to reboot. So I don't have benchmark machine for now. Please prioritize LOAD_NONE/LOAD_COMMON_CONST than this. It is hard to maintain merged branches. Merging LOAD_NONE

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: I used this tool to count co_const size and numbers. https://github.com/faster-cpython/tools/pull/6 Target is asyncio in the main branch. main (b34dd58f): Total: 31 files; 1,068 code objects; 12,741 lines; 39,208 opcodes; 3,880 total size of co_consts; 738 numb

[issue36521] Consider removing docstrings from co_consts in code objects

Mark Shannon added the comment: I strongly favor (b) over (d). (d) adds more complexity to MAKE_FUNCTION. MAKE_FUNCTION represents a measurable fraction of execution time for many programs. The more flags and branches it has, the harder it is to optimize. -- ___

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > I'm not in favor of (c) co_doc either any more (for the reasons you state). I > would go for (b), a CO_DOCSTRING flag plus co_consts[0]. I expect that > co_consts sharing to be a very minor benefit, but you could easily count this > with another small change

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Not so fast. I'm not in favor of (c) co_doc either any more (for the reasons you state). I would go for (b), a CO_DOCSTRING flag plus co_consts[0]. I expect that co_consts sharing to be a very minor benefit, but you could easily count this with another sm

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > There is a clear disadvantage in moving the docstring from the function's > code object to the enclosing code object: > > Docstrings are rarely looked at (relative to other operations on functions). > Inner functions and comprehensions are created many times f

[issue36521] Consider removing docstrings from co_consts in code objects

Mark Shannon added the comment: There is a clear disadvantage in moving the docstring from the function's code object to the enclosing code object: Docstrings are rarely looked at (relative to other operations on functions). Inner functions and comprehensions are created many times for the s

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: Mark, would you take a look, please? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Let's wait until Mark Shannon is back from vacation (another week). Note that class docstrings *are* contained in the class body code object -- there's executable code equivalent to __doc__ = "this is the docstring" But I agree it's not easily found witho

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > I am still not convinced that it's a good idea to put the docstring in the > surrounding code object. I'd like to be able to see it when I introspect a > code object, not just when introspecting a function object (I may be > analyzing code only, and it's hard

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: I am still not convinced that it's a good idea to put the docstring in the surrounding code object. I'd like to be able to see it when I introspect a code object, not just when introspecting a function object (I may be analyzing code only, and it's hard to

[issue36521] Consider removing docstrings from co_consts in code objects

Change by Inada Naoki : -- keywords: +patch pull_requests: +26577 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28138 ___ Python tracker ___

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: This is WIP pull request. https://github.com/methane/cpython/pull/35 Some tests are failing because of bpo-36521. -- ___ Python tracker ___

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: I grepped top 5000 downloaded packages and I can not find any real use of PyFunction_New(WithQualName). So I don't know what is current workflow of PyFunction_New. My current wip implementation adds new API (e.g. PyFunction_NewWithDoc()). Old API keep using co_c

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: I think we shouldn't change *which* code object contains the docstring (changing anything about that is likely to disturb someone's workflow in a way that's hard to fix) -- only how PyFunction_New finds that docstring in the code object (if that breaks som

[issue36521] Consider removing docstrings from co_consts in code objects

Irit Katriel added the comment: Are you suggesting that anyone who calls PyFunction_New needs to add a doc string assignment following the call? This is public api, so that would break people’s working code. -- ___ Python tracker

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > I think that would require a change in the signature of PyFunction_New. I don't think so. For example, func_annotation don't require changing PyFunction_New(). ``` case TARGET(MAKE_FUNCTION): { PyObject *codeobj = POP(); PyFunc

[issue36521] Consider removing docstrings from co_consts in code objects

Serhiy Storchaka added the comment: If we are going to move docstring out of co_consts, I would make it a code object attribute rather than argument of MAKE_FUNCTION. It saves time on function creation. Most functions do not change docstring after creation. It is the same as code docstring,

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > If docstring is not in co_consts, all co_consts are empty tuple. The empty > tuple is nearly zero-cost because its a singleton. My wrong. Two setters will have `(None,)` tuple. But such tuple can be merged at compile time for now. And "common const" [1] appro

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > Why all the hating on docstrings? What have docstrings done wrong? Oh, I don't hate docstrings. I just want to move it from code object to function object. Remove docstring during unmarshal is your idea, not mine. My main motivation is reducing code size. Se

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: Why all the hating on docstrings? What have docstrings done wrong? I know there's the -OO flag that strips docstrings, but it doesn't work well and I think it was a mistake. -- ___ Python tracker

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > This would actually make it harder to strip docstrings e.g. during > unmarshalling, since you don't know which constants refer to docstrings. We can not strip class docstring anyway. One idea to strip docstring during startup: Add new opcode only for storing

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: > You'd just be moving the problem though -- the docstring would have be > included in the co_consts array of the surrounding code object instead of the > function object. As far as I know, surrounding code objects (e.g. global, class body) will be removed rig

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: > I'd like to remove docstring from code object at all. > func.__doc__ can be set by MAKE_FUNCTION or STORE_ATTR. You'd just be moving the problem though -- the docstring would have be included in the co_consts array of the surrounding code object instead o

[issue36521] Consider removing docstrings from co_consts in code objects

Irit Katriel added the comment: > I'd like to remove docstring from code object at all. > func.__doc__ can be set by MAKE_FUNCTION or STORE_ATTR. I think that would require a change in the signature of PyFunction_New. -- ___ Python tracker

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: I'd like to remove docstring from code object at all. func.__doc__ can be set by MAKE_FUNCTION or STORE_ATTR. Pros are: * Code objects can be bit smaller than adding co_doc. * Many code objects don't have docstrings. (e.g. lambdas, somprehensions, and PEP 649

[issue36521] Consider removing docstrings from co_consts in code objects

Guido van Rossum added the comment: In 3.11 the code object will definitely change. We may well put the docstring in a dedicated attribute. -- nosy: +Guido.van.Rossum versions: +Python 3.11 -Python 3.8 ___ Python tracker

[issue36521] Consider removing docstrings from co_consts in code objects

Change by Irit Katriel : -- nosy: +gvanrossum, iritkatriel ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue36521] Consider removing docstrings from co_consts in code objects

Inada Naoki added the comment: There is idea about reading docstring lazily, when func.__doc__ is accessed. I don't think the idea can be implemented by 3.8. But if we change code object now, I want new API can be used to implement this idea. One breaking change is better than two. ---

[issue36521] Consider removing docstrings from co_consts in code objects

Terry J. Reedy added the comment: So we have the same issue with f.__name__ and f.__code__.co_name becoming unsynchronized. FWIW, I would prefer that the code docstring be co_doc, rather than hidden in co_constants, so that 'name' and 'doc' follow the same pattern. -- nosy: +terry.r

[issue36521] Consider removing docstrings from co_consts in code objects

Serhiy Storchaka added the comment: I think it is for historical reasons. Currently statements consisting of a constant expression are not compiled to a bytecode and do not add a value to co_consts. But when this optimization was not yet added, the first element of co_consts with a docstring

[issue36521] Consider removing docstrings from co_consts in code objects

Change by Inada Naoki : -- nosy: +inada.naoki ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue36521] Consider removing docstrings from co_consts in code objects

Raymond Hettinger added the comment: > co_consts[0] is used for setting the initial value of __doc__. Why is __doc__ set this way, but __name__ is set directly on the function object? Setting __doc__ from the code object seems like an odd implementation hack that puts the responsibility in

[issue36521] Consider removing docstrings from co_consts in code objects

Serhiy Storchaka added the comment: co_consts[0] is used for setting the initial value of __doc__. See PyFunction_NewWithQualName(). consts = ((PyCodeObject *)code)->co_consts; if (PyTuple_Size(consts) >= 1) { doc = PyTuple_GetItem(consts, 0); if (!PyUnicode_Check(doc)

[issue36521] Consider removing docstrings from co_consts in code objects

New submission from Raymond Hettinger : Function objects provide __doc__ as a documented writeable attribute. However, code objects also have the same information in co_consts[0]. When __doc__ is changed, the latter keeps a reference to the old string. Also, the disassembly shows that co_c