[tahoe-lafs-trac-stream] [tahoe-lafs] #97: reducing memory footprint in share reception

[tahoe-lafs]

#97: reducing memory footprint in share reception
------------------------+---------------------------------------------
     Reporter:  warner  |      Owner:  warner
         Type:  defect  |     Status:  assigned
     Priority:  major   |  Milestone:  undecided
    Component:  code    |    Version:  0.4.0
   Resolution:          |   Keywords:  performance memory upload large
Launchpad Bug:          |
------------------------+---------------------------------------------

Comment (by davidsarah):

 warner wrote:
 > I also have some suspicions about the way that nested functions work: do
 they capture the state of all local variables, or just the ones that are
 referenced in their body?

 You are right to be suspicious: in CPython closures keep a reference to
 the entire enclosing frame. See Owen S.'s answer at
 http://stackoverflow.com/questions/3145893/how-are-closures-implemented-
 in-python .

 BTW, this approach not only leads to memory leaks, but also gives the
 wrong -- or at least, unexpected by most programmers -- semantics for
 captured mutable variables. And since changing that would be an
 incompatible change, it's not likely that either the memory leaks or the
 semantics will be fixed.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/97#comment:12>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage