code objects should conserve memory

[nnorwitz]

BPO	2185
Nosy	@abalkin
Files	marshal-mem.patch: reduce code objects in memory from marshal.

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-03-15.22:47:47.581>
created_at = <Date 2008-02-25.02:41:40.315>
labels = ['performance']
title = 'code objects should conserve memory'
updated_at = <Date 2008-03-15.22:47:47.580>
user = 'https://bugs.python.org/nnorwitz'

bugs.python.org fields:

activity = <Date 2008-03-15.22:47:47.580>
actor = 'nnorwitz'
assignee = 'none'
closed = True
closed_date = <Date 2008-03-15.22:47:47.581>
closer = 'nnorwitz'
components = []
creation = <Date 2008-02-25.02:41:40.315>
creator = 'nnorwitz'
dependencies = []
files = ['9547']
hgrepos = []
issue_num = 2185
keywords = ['patch']
message_count = 3.0
messages = ['62965', '63085', '63568']
nosy_count = 2.0
nosy_names = ['nnorwitz', 'belopolsky']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'resource usage'
url = 'https://bugs.python.org/issue2185'
versions = ['Python 2.6']

[nnorwitz]

Various bits are often duplicated in code objects. For example,
sometimes names and varnames are equal. In this case, we don't need two
objects since they are both const. This patch implements a trivial fix
for this case. However, there are more cases. We should profile where
the memory is being used and do simple/cheap consolidations where
possible. Another example would be a 1-element tuple containing:
(None,) for consts.

Some (all?) of these sorts of optimizations should probably be done in
the code object itself.

[abalkin]

Since names and varnames are known to be tuples of interned strings,
they can be compared without calling abstract API. Just compare sizes
and then compare item pointers in a loop.

What are the cases when co_names == co_varnames? How often is this the
case in the wild?

[nnorwitz]

Marshal is the wrong place for this sort of thing (the code object is
where it should be done).

I botched the analysis. The case is common, but only for the empty
tuple which I forgot to ignore. (None,) was a common case when I
measured it. We should measure the actual memory savings before
anything is implemented.

To answer your question, the case were this happens is:

  def foo(self):  return self.self