Mike Pall wrote: > What I meant with 'less malloc-happy' is that we should try to reduce > the number of allocations/deallocations for internal (!) objects (I'm not > talking about objects explicitly managed by the application). Many of them > have a very short time-to-live. I guess some of them could be recycled or > even optimized away. > > E.g. global profiling indicates that tuple allocation/deallocation has a > noticeable effect on performance. There are probably other objects that > have prohibitive setup/teardown cost (but are less pronounced on allocation > costs). The problem is that this has already been done in the past. Anybody contributing to the Python core is certainly aware that avoiding memory allocations, where possible, should be done, and indeed, special cases have been added (e.g. my addition of METH_NONE and METH_O to avoid tuple creation). So unless a specific proposal is made, I'm doubtful that much optimization is possible without breaking core semantic aspects of the language. Regards, Martin
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