From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Thu Apr 25 2013 - 06:40:58 CDT

On Thu, Apr 25, 2013 at 11:29 AM, Jrme Hnin <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.