Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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