View app consuming memory
[1/10] from: amicom::sonic::net at: 12-Jun-2003 16:04
Does anyone know how to get the following to not eat memory?
view/new main-box: make face [size: 100x300]
loop 100 [
recycle probe system/stats ;show memory usage
main-box/pane: layout [slider rate 10]
show main-box
]
This was reduced from a MUCH more complicated commercial program in daily
use, and the memory consumption problem is much more pronounced in that
environment, but stems back (at least partially) to this.
It is such a problem that it is not uncommon for a single instance of the
program to be using over 100MB after a few hours of usage as each time the
non-simplified version of the above is called, it consumes between 2 and
3MB of memory.
Normally, the slider also has an 'engage function attached to it (which is
triggered by 'rate), but that was removed for clarity. The problem doesn't
seem to happen other than with 'rate enabled on the facet (at least it
hasn't in my tests). It does not appear to be limited to the 'slider facet.
Even after 'unview/all and 'recycle, most of the memory consumed is still
not returned.
It appears to be a memory consumption bug to me.
Any input would be greatly appreciated!
Bohdan "Bo" Lechnowsky
Lechnowsky Technical Consulting
[2/10] from: rotenca:telvia:it at: 13-Jun-2003 2:26
Hi,
> Does anyone know how to get the following to not eat memory?
view/new main-box: make face [size: 100x300]
main-box/pane: layout [sl: slider rate 10]
loop 1000 [
probe system/stats ;show memory usage
sl/rate: none
show sl
main-box/pane: layout [sl: slider rate 10]
show main-box
]
> triggered by 'rate), but that was removed for clarity. The problem doesn't
> seem to happen other than with 'rate enabled on the facet (at least it
> hasn't in my tests). It does not appear to be limited to the 'slider facet.
I saw something like this, also without 'rate in others programs (recyle
error, random crash and so on), but i was not able to reduce the problem in
simple code.
Recycling seems not perfect with faces.
I often get an easy solution re-using the same faces.
---
Ciao
Romano
[3/10] from: jeff:rebol at: 12-Jun-2003 17:33
Try killing the rate before you strand the object referred to
by the slider. Ie:
probe system/stats
view/new main-box: make face [size: 100x300]
show main-box
loop 100 [
main-box/pane: layout [x: slider rate 10]
show main-box
x/rate: none
show main-box
recycle
]
unview/all
probe system/stats
halt
-jeff
On Thu, Jun 12, 2003 at 04:04:52PM -0700, Bohdan or Rosemary Lechnowsky wrote:
[4/10] from: nitsch-lists:netcologne at: 13-Jun-2003 3:23
Romano Paolo Tenca wrote:
>Hi,
>>Does anyone know how to get the following to not eat memory?
<<quoted lines omitted: 12>>
>>hasn't in my tests). It does not appear to be limited to the 'slider facet.
>>
because 'rate runs even if we throw the face away. And so does not get
garbage-collected:
view/new main-box: make face [size: 300x300]
main-box/pane: layout [
sl: slider rate 10
feel [engage: func [f a e] [probe random 6]] ; will run without face
visible..
]
show main-box
main-box/pane: layout [text "no slider"]
show main-box
do-events
[5/10] from: g:santilli:tiscalinet:it at: 13-Jun-2003 9:51
Hi Bohdan,
On Friday, June 13, 2003, 1:04:52 AM, you wrote:
BoRL> It appears to be a memory consumption bug to me.
Probably. Maybe you have to set the rate to none and show the face
first, or it will remain referenced internally and thus won't be
recycled?
view/new main-box: make face [size: 100x300]
loop 100 [
recycle probe system/stats ;show memory usage
main-box/pane: layout [s: slider rate 10]
show main-box
s/rate: none
show s
]
It seems to work here.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[6/10] from: cyphre:seznam:cz at: 13-Jun-2003 11:38
Hi All,
----- Original Message -----
From: "Volker Nitsch" <[nitsch-lists--netcologne--de]>
To: <[rebol-list--rebol--com]>
Sent: Friday, June 13, 2003 3:23 AM
Subject: [REBOL] Re: View app consuming memory
........
> because 'rate runs even if we throw the face away. And so does not get
> garbage-collected:
<<quoted lines omitted: 9>>
> do-events
> >
You can use also HIDE command to stop all rates easily...it is handy when
you are using structure of nested faces with RATE so you don't have to set
all the RATEs to none.
view/new main-box: make face [size: 300x300]
main-box/pane: layout [
box rate 10
feel [engage: func [f a e] [probe join "box " random 6]] with [
pane: layout [
sl: slider rate 10
feel [engage: func [f a e] [probe join "slider " random 6]]
]
]
]
show main-box
hide main-box/pane ;try to comment this line :)
main-box/pane: layout [text "no slider, no box :)"]
show main-box
do-events
(BTW this functionality has been requested by me two years ago ;-)).
Anyway sometimes we need to remove the time events without hiding the
face(s) but how to do it??
Holger said looong time ago: "For removing timeouts without hiding a face ?
The solution is probably something like "face/changes: 'timeout show face"
in the next version. We are already using face/changes in some other places
to limit the work show has to do, and to avoid flickering. Seems like a
natural addition."
Unfortunately this feature is still not available in View so I hope RT will
add it into the next 1.3 View.
regrads,
Cyphre
[7/10] from: rotenca:telvia:it at: 13-Jun-2003 13:13
I have found an example of failure without rate:
x: [button "open" [inform layout x]]
inform layout x
Usage:
Click on "open" until Rebol crashes.
In my experience, this can happen also when windows are closed or face are
removed from pane, but it is more random and hard to duplicate.
---
Ciao
Romano
[8/10] from: nitsch-lists:netcologne at: 13-Jun-2003 15:08
Romano Paolo Tenca wrote:
>I have found an example of failure without rate:
>
>x: [button "open" [inform layout x]]
>inform layout x
>
>Usage:
>
> Click on "open" until Rebol crashes.
>
?>> source inform
inform: func [
..
] [
..
either time [wait time] [do-events]
]
each open calls inform calls wait. Deep wait-recursion. Could that be
the problem?
[9/10] from: rotenca:telvia:it at: 13-Jun-2003 17:07
>> source inform
> inform: func [
<<quoted lines omitted: 5>>
> each open calls inform calls wait. Deep wait-recursion. Could that be
> the problem?
I think you are right. Holger had said that it is not safe to call a wait from
event code. But if this rule is applied literally, Inform cannot be used in
view code. The strange thing is that it fails only after a large (fixed?)
number of calls. Perhaps exists a fixed limit in wait recursion.
In this case the memory garbage collector does not seems the problem.
---
Ciao
Romano
[10/10] from: antonr:iinet:au at: 14-Jun-2003 22:10
Does anyone think that there might be a place
in the system object somewhere where there is
a reference to all such faces with timeouts
on them? I am meaning to try to bugfix that
find-objects.r script that came up a while ago.
(a recursive system trawler).
Anton.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted