CPU problem

[epopov]

Hi, I tried to make simple application, that creates and removes rectangles from canvas. But when my application works more then 2-3 minutes it will use 90% CPU. Tell me what I did wrong.
The code is in attachment.

[antun]

There is a known memory leak with deleting views using deleteView() in v1 (1.0.x). This could well be what you're seeing. I recommend not deleting views, but rather setting their visible to off.

Also remember that the view creation process is processor-intensive on its own. In your app, you are creating a view onidle (i.e. all the time). That in itself is going to be expensive. The fact that removing the views doesn't really free up any memory does not help either.

In general, we recommend that you write declarative code over instantiative. Might I ask why you're creating so many views at once?

-Antun

[epopov]

Because I must create a lot of simple objects in my application.

[antun]

Is there no way around this? Can you not turn visibility on and off?

-Antun

[antun]

The 2.0 Preview release is out now, and you can download it at:

http://www.laszlosystems.com/developers/download/

The memory leak issue I mentioned is fixed now.

-Antun

[epopov]

I changed deleteView to destroy in this test file and the same problem as in v.1 appeared. May be I need to change something else?

The problem: during 5b minutes of playing this test CPU grows to 100%.

[adam]

Hiya pop,
I'm afraid this is expected behavior. New'ing and destroying a view is a fairly expensive operation. As Antun suggested, an effect like this one would be better achieved by using a pool of views which are hidden and shown.

In general, if you run code on the frame hook and if that code takes longer than 1/30th of a second to run, then it'll peg the cpu. I added a stop button to your app (which calls canvas.monitorDel.unregisterAll() ) and the app is ok to do other stuff -- in other words new'ing and destroying these views doesn't corrupt the general state of the runtime (e.g. the debugger still works with normal perf characteristics.) Also, the memory usage of this app does not appear to grow unboundedly.

One thing that might be happening is that the runtime may be slightly slower processing large values of i and j. I added some code that made i and j cycle when they got to 1000 (and changed the logic in monitorX appropriately) and the performance of the app was fairly stable in a long run (~10 minutes.)

Anyway, I recognize this isn't a lot of help, but this behaves the way I would expect it to. If you're seeing a dramatic slowdown after 5 minutes, please reply here -- that's not what I'm seeing.