| Author |
What's causing this memory usage?
|
|
| shamil 2005-10-19, 3:57 am |
| After spending a couple of hours on this, I've given up trying to
figure out why the memory usage keeps going up in my application for
the first 10 minutes or so --until it slowly stabilizes. I've
basically narrowed it down to the proc that's causing it and below is a
simple example to demonstrate the problem. I'm guessing that
continuously calling the loop proc is contributing to this, but don't
know how to take care of it. Any thoughts? (I'm on Tk8.5 WinXP)
#################### Begin script ####################
proc loop {w value1 value2 interval} {
global start
$w config -background $value1
set timing [expr [clock seconds]-$start]
# I'm on the east cost
# only show day(s) if more than 24 hrs
if {[set v1 [expr int($timing/86400)]] < 1} {
set daywatch ""
} elseif {$v1 == 1} {set daywatch "1 day and"
} else {set daywatch "$v1 days and"}
set hourwatch [clock format [expr {$timing+18000}] -format %T]
$w configure -text "Stopwatch: $daywatch $hourwatch"
after $interval [concat loop $w $value2 $value1 $interval]
}
set start [clock seconds]
label .l
pack .l
loop .l pink red 1000
#################### End script ####################
| |
| Donald Arseneau 2005-10-19, 7:59 am |
| "shamil" <shamild@hotmail.com> writes:
> After spending a couple of hours on this, I've given up trying to
> figure out why the memory usage keeps going up in my application for
> the first 10 minutes or so --until it slowly stabilizes. I've
> basically narrowed it down to the proc that's causing it and below is a
> simple example to demonstrate the problem. I'm guessing that
> continuously calling the loop proc is contributing to this, but don't
> know how to take care of it. Any thoughts? (I'm on Tk8.5 WinXP)
I don't see any memory leak in the loop (although I think you should
use [list ] when you re-schedule the loop, not [concat ]).
Does the memory grow when you run just this script in a bare-bones wish?
I'm wondering if you have some debugging helpers that log all the
command executions; or maybe some variable traces.
--
Donald Arseneau asnd@triumf.ca
| |
| shamil 2005-10-19, 7:00 pm |
| Donald,
Yes...the memory keeps growing when I run just this script in wish. The
rate of growth goes down over time, but it keeps growing nonetheless.
The reason I used [concat] was based on an argument by Bruce Hartweg
back in 2001 at the following thread:
http://groups.google.com/group/comp...f84c63e7e0fa4e/
I re-ran the script and tried [list] and also without either [concat]
or [list]. I observed each scenario for 30 minutes and my
non-scientific conclusion is that it grows slower when using [list] or
nothing than it does with [concat], but the bad news is the memory
still keeps growing!!
Regards
-Shamil
Donald Arseneau wrote:
> "shamil" <shamild@hotmail.com> writes:
>
>
> I don't see any memory leak in the loop (although I think you should
> use [list ] when you re-schedule the loop, not [concat ]).
>
> Does the memory grow when you run just this script in a bare-bones wish?
> I'm wondering if you have some debugging helpers that log all the
> command executions; or maybe some variable traces.
>
>
> --
> Donald Arseneau asnd@triumf.ca
| |
| Bryan Oakley 2005-10-19, 7:00 pm |
| shamil wrote:
> Donald,
>
> Yes...the memory keeps growing when I run just this script in wish. The
> rate of growth goes down over time, but it keeps growing nonetheless.
>
> The reason I used [concat] was based on an argument by Bruce Hartweg
> back in 2001 at the following thread:
>
> http://groups.google.com/group/comp...f84c63e7e0fa4e/
>
The use of concat in that thread is used for a specific reason. It was
taking a list ($args) and building a new list that was to be a superset
of the original list. There is most definitely a difference between this:
set code [list foo $args]
and this:
set code [concat foo $args]
The former creates a list of exactly two elements, no matter how many
elements are in $args. The latter creates a list that is 1 longer than
the llength of $args.
In your case, you weren't creating a new list based on an old list, so
the proper usage is [list] rather than [concat]
| |
| Kaitzschu 2005-10-19, 7:00 pm |
| On Wed, 19 Oct 2005, shamil wrote:
> The reason I used [concat] was based on an argument by Bruce Hartweg
> back in 2001 at the following thread:
>
> http://groups.google.com/group/comp...f84c63e7e0fa4e/
That is an issue only when used with magic parameter args. Args is a list,
always a list. If you call a proc that has args
proc foo {args} {}
by
foo a b c
then args is a list {a b c}. If you after that reschedule foo (inside foo)
with
after 12345 [list foo $args]
you get nesting list (listifying already listified variable args). You
don't use magic parameter args, so you are safe to use [list].
Just to clarify :)
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
| |
| Bryan Oakley 2005-10-19, 7:00 pm |
| Kaitzschu wrote:
>
> That is an issue only when used with magic parameter args. Args is a
> list, always a list.
Let's not get too hasty with that "always" declaration. In common
practice it's always a list, but that's only half the story. The truth
is that it's only a list if used as the last formal argument in a proc
definition. Then, it's always a list.
(does anybody ever use $args for anything except the last formal
argument in a proc definition?)
Bryan "Sometimes it's fun to be a pedant" Oakley
| |
| Donald Arseneau 2005-10-19, 7:00 pm |
| Bryan Oakley <oakley@bardo.clearlight.com> writes:
> (does anybody ever use $args for anything except the last formal argument in
> a proc definition?)
Only when they enter an obfuscated Tcl contest :-)
--
Donald Arseneau asnd@triumf.ca
| |
| Donal K. Fellows 2005-10-19, 7:00 pm |
| shamil wrote:
> After spending a couple of hours on this, I've given up trying to
> figure out why the memory usage keeps going up in my application for
> the first 10 minutes or so --until it slowly stabilizes. I've
> basically narrowed it down to the proc that's causing it and below is a
> simple example to demonstrate the problem. I'm guessing that
> continuously calling the loop proc is contributing to this, but don't
> know how to take care of it. Any thoughts? (I'm on Tk8.5 WinXP)
There's nothing particularly obvious there, but try the following small
changes:
* Put {braces} round the expressions
* Use [list] to construct the callback script and not [concat]
Donal.
| |
| chengye.geo@yahoo.com 2005-10-19, 9:57 pm |
| I did timing for the [clock format $s -format %T] in a Windows XP (AMD
3200/64 cpu and 512MB)
In Tcl 8.5a4
% set s [clock seconds]
% time "clock format $s -format %T" 100
410.94 microseconds per iteration
In Tcl 8.4.7
% set s [clock seconds]
% time "clock format $s -format %T" 100
9 microseconds per iteration
The speed has significantly dropped in Tcl 8.5a4. I'm afraid this
will have a negative impact on time-critical applicaitons (.e.g, data
acquisitions) showing the clock updating.
| |
| Donal K. Fellows 2005-10-20, 7:57 am |
| chengye.geo@yahoo.com wrote:
> The speed has significantly dropped in Tcl 8.5a4. I'm afraid this
> will have a negative impact on time-critical applicaitons (.e.g, data
> acquisitions) showing the clock updating.
Yes, but:
clock format $s -format %+ -locale fr_FR -timezone Asia/Tokyo
just isn't possible in 8.4. Some you win, some you lose.
Donal.
| |
| Uwe Klein 2005-10-20, 7:57 am |
| Donal K. Fellows wrote:
> chengye.geo@yahoo.com wrote:
>
>
>
> Yes, but:
> clock format $s -format %+ -locale fr_FR -timezone Asia/Tokyo
> just isn't possible in 8.4. Some you win, some you lose.
>
> Donal.
Upto now i used a read trace to produce formatted timestamps for logging.
A 50fold increase in computing time for [clock format ...] would not be
acceptable.
"Simple" formats should not loose that much!
Even if you try to work around this ( see second script ) some other drag
shows up. (8us --> 50us )
uwe
<testscript clocktest.tcl>
proc now {args} {
set seconds [ clock seconds ]
set ::now [ clock format $seconds -format %Y%jT%H:%M:%S ]
}
trace variable ::now r now
set res [ time {set ::now} 1000 ]
puts "$res"
</script>
<results>
uwe@ben:~/tcltest> tclsh8.5 clocktest.tcl
1982 microseconds per iteration
uwe@ben:~/tcltest> tclsh8.5 clocktest.tcl
1975 microseconds per iteration
uwe@ben:~/tcltest> tclsh8.5 clocktest.tcl
1980 microseconds per iteration
uwe@ben:~/tcltest> tclsh8.4 clocktest.tcl
19 microseconds per iteration
uwe@ben:~/tcltest> tclsh8.4 clocktest.tcl
17 microseconds per iteration
uwe@ben:~/tcltest> tclsh8.4 clocktest.tcl
18 microseconds per iteration
<testscipt two>
set ::seconds 0
proc now {args} {
set sec [ clock seconds ]
if {$sec != $::seconds} {
set ::now [ clock format $sec -format %Y%jT%H:%M:%S ]
set ::seconds $sec
}
}
trace variable ::now r now
puts $::now
set res [ time {set ::now} 1000 ]
puts "$res"
</script>
<results two>
uwe@ben:~/tcltest> tclsh8.4 clocktest.tcl
2005293T14:35:48
8 microseconds per iteration
uwe@ben:~/tcltest> tclsh8.5 clocktest.tcl
2005293T14:35:50
52 microseconds per iteration
| |
| Kaitzschu 2005-10-20, 7:00 pm |
| On Thu, 20 Oct 2005, Uwe Klein wrote:
> Upto now i used a read trace to produce formatted timestamps for
> logging. A 50fold increase in computing time for [clock format ...]
> would not be acceptable.
> "Simple" formats should not loose that much!
As I have been told here, clock commands for 8.5 are still in optimizing
stage. As you can most likely see from
time {clock seconds} 25000
that gives ~100 microseconds per iteration with 8.4.11, and ~300 with
8.5a3. I doubt any recent hardware can show you this difference, but it is
there (my vintage rocks :)
So if basic clock commands are triple the time, what can you expect from
more complex commands. But that just makes me eagerly wait for future
releases (it is still 5% CPU load just to show my clock).
But I do have faith in [clock] maintainer(s), if we (the users) have hard
time accepting this performance drop, the coder(s) must be losing their
night sleep for it. I have had sleepless nights for less :)
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
| |
| Donal K. Fellows 2005-10-20, 7:00 pm |
| Kaitzschu wrote:
> But I do have faith in [clock] maintainer(s), if we (the users) have
> hard time accepting this performance drop, the coder(s) must be losing
> their night sleep for it. I have had sleepless nights for less :)
Actually, we've collectively been worrying more about bignums.
Donal.
| |
| Andreas Leitgeb 2005-10-20, 7:00 pm |
| Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
> chengye.geo@yahoo.com wrote:
>
> Yes, but:
> clock format $s -format %+ -locale fr_FR -timezone Asia/Tokyo
> just isn't possible in 8.4. Some you win, some you lose.
If the price for new functionality is *so* high,
then perhaps it should be put in a new subcommand...
| |
| Kaitzschu 2005-10-20, 7:00 pm |
| On Thu, 20 Oct 2005, Donal K. Fellows wrote:
> Kaitzschu wrote:
>
> Actually, we've collectively been worrying more about bignums.
For now, but sooner or later Tcl (v27.2.6?) will be near perfect, you are
getting ready for the best night sleep ever, and you remember this. It is
just a matter of time :)
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
|
|
|
|