From: Jérôme Hénin (jerome.henin_at_ibpc.fr)
Date: Thu Apr 25 2013 - 06:43:38 CDT

Thanks for the detailed explanations, Axel.

Sorry for the misleading statements, which have laid bare my simplistic views of this. I find comfort in the fact that I have elicited a better answer from someone more knowledgeable.

Maybe you'll admit that I was fooled by a mechanism that seems designed to look like, feel like, and work like a garbage collector -- and possibly smell like one, if I read you well.

Cheers,
Jerome

----- Original Message -----
> On Thu, Apr 25, 2013 at 11:29 AM, Jérôme Hénin <jerome.henin_at_ibpc.fr>
> wrote:
> > Alternately, if you use the atomselect object only once, you can
> > take
> > advantage of the Tcl garbage collector:
> >
> > [atomselect top "some selection text"] somecommand
>
> in my personal opinion this is bad coding style and should *not* be
> recommended. please see below why.
>
> > The script keeps no reference to the atomselect object, so it gets
> > deleted
> > automatically.
>
> sorry, but this is *not* how it works.
>
> the atomselect command always creates a new commands, atomselect#
> (with # being a continuously increasing number), and new commands
> always have a global(!) scope. the reason why it behaves like it has
> local scope is due to the "upproc" function as it is defined in
> atomselect.tcl. this will *also* create a proxy variable
> (upproc_var_<name>) with a trace attached to it, so as soon as the
> upproc_var_<name> would go out of scope the command upproc_del is
> called to also remove the thusly "localized" command.
>
> this is one of the really nasty legacy things in VMD that are causing
> all kinds of unexpected behavior, especially when dealing with
> plugins
> and namespaces, since this method only knows global or local scope.
> in
> addition it adds a *significant* overhead through the many traces,
> yet
> it doesn't solve the majority of atomselect related memory leak
> issues
> in VMD, since those happen inside of loops where the scope is not
> changed. things would be *much* more consistent and predictable, if
> this "localizing" of atomselect procedures would be eliminated. the
> transitional problems in having to improve code that works because of
> this localization behavior (and my guess is that most of that code is
> not leaking memory by accident rather than by design) i would
> consider
> small compared to benefits for writing more sophisticated plugins
> (e.g. where selections could be stored in lists or arrays and
> returned
> as return values of functions without forcing them to be global).
>
>
> > Another way this happens is when the variable referencing the
> > object goes
> > out of scope, e.g. if it is local to a procedure:
> >
> > proc getnum { selText } {
> > set sel [atomselect top $selText]
> > return [$sel num]
> > }
> >
> > When this proc finishes, its local variable sel goes out of scope,
> > the
> > reference count to the atomselect object goes to zero, and it gets
> > deleted.
>
> again, atomselect is not creating objects but procedures, i.e. new
> entries in the interpreter.
>
> > Now suppose I want a very stupid way to multiply the number of
> > atoms in the
> > system by ten thousand, I could do:
> >
> > set num 0
> > for { set i 0 } { $i < 10000 } { incr i } {
> > incr num [getnum all]
> > }
> > puts $num
> >
> > This doesn't leak any memory. It works because the variable sel is
> > never
> > *overwritten* - that's when memory leaks happen.
>
> it works because you are calling a procedure, genum, which
> "localizes"
> the corresponding upproc_var_atomselect<#> variable to the getnum
> function.
>
> axel.
>
>
> >
> > Cheers,
> > Jerome
> >
> >
> > ________________________________
> >
> >
> > Reassigning the variable doesn't delete the atomselect object. I
> > have
> > learned the hard way to always follow the pattern:
> >
> >
> > set sel [atomselect top "some selection text"]
> > ... do something with the $sel ...
> > $sel delete
> >
> >
> > especially when the selection comes in a loop.
> >
> >
> >
> >
> > On Apr 24, 2013, at 4:51 PM, Lorenzo Gontrani wrote:
> >
> >
> >
> >
> > Dear VMD users and developers, I need to calculate several rdfs
> > for
> > quite large trajectories, and, from some tests I ran, I could see
> > that the GPU version of gofr script (rdf) is actually very fast,
> > but
> > I noticed that i cannot easily calculate all the rdf together (i.
> > e.
> > launching vmd -dispdev only once) because the memory usage grows
> > very rapidly with multiple selections. I read in the old posts
> > that
> > it should be possible to delete the selection with $sel delete (at
> > the moment, my script overwrites sel1 and sel2, but a different
> > "atomselect??" is echoed on the screen, so I guess that it is a
> > new
> > selection and the variable is not overwritten). Does anybody have
> > experience about that?
> >
> > Thanks a lot for any help
> > Lorenzo
> >
> >
> >
> > --
> > ==========================================
> > Lorenzo Gontrani
> > Research associate of CNR-ISM (Rome Tor Vergata)
> > EDXD group of University of Rome "La Sapienza"
> >
> > GSM +39 338 7615798
> > Email lorenzo DOT gontrani AT gmail DOT com
> > Webpage: http://webcaminiti/gontrani.html
> > =========================================
> > Rispetta l'ambiente: se non è necessario, non stampare
> > questa e-mail
> > Protect the environment: do not print this e-mail, unless
> > necessary
> >
> >
>
>
>
> --
> Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0
> International Centre for Theoretical Physics, Trieste. Italy.
>