VMD-L Mailing List

From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Thu Apr 25 2013 - 07:29:54 CDT

On Thu, Apr 25, 2013 at 1:43 PM, Jérôme Hénin <jerome.henin_at_ibpc.fr> wrote:
> 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.

...and i am grateful for having another opportunity to plead for
removal of this monstrosity. ;-)

> 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

absolutely.

> -- and possibly smell like one, if I read you well.

yup. it is obviously a feature that was implemented and added with the
best intentions. if atom selections would be used differently, it
might even be considered a good feature.

this is certainly an area where Tcl suffers from not being a more
object oriented language.

axel.

>
> 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.
>> 

--
Dr. Axel Kohlmeyer  akohlmey_at_gmail.com  http://goo.gl/1wk0
International Centre for Theoretical Physics, Trieste. Italy.