maybe try to remark parts of the app that they are not used and see the result.
and try to exclude this “intensive graphics program”, that it not affect the xojo app/ui.
can you test the app at other pc with other graphics manufacturer and/or driver?
Use the profiler to see which methods are called the most offen, probably youll see an exponention growth of calls from some method that tries to keep up.
I’m guessing it’s some kind of mouse movement event being called often, that has too much code in it.
1 Like
I’ve seen this behavior in apps that have an async messaging system in them, usually caused by not removing things from the message queue when they’re no longer relevant. I can elaborate if you think you’re using a system like that.
And no, that wouldn’t be revealed as a leak if you’re using WeakRefs (which you absolutely should)
Hi Greg, this certainly could be the case.
I’m not really across the detail of what you’re suggesting so an elaboration would be fantastic.
I suspect you’re talking about the payload changing between messages? If so, it’s probably not the case as we have a defined communication protocol using JSON between devices where all data is updated in each message, but I may not be on the right track…
I think Greg is referring to the internal operations of your app. Do you have an internal message queue that objects use to send messages to each other? If your app has something like this and it isn’t being properly cleaned up (i.e., if the objects aren’t being destroyed) then it could cause problems like this after some time has passed.
1 Like
Thanks Eric,
Would that be a variable array or something similar that is/should be getting bigger?
Yes, it must be something like that. If you had objects that aren’t been destroyed you should have seen those in the memory leak checker.
Probably but not necessarily. Frankly, if you have to ask, it’s unlikely to be the problem; this would be something you would have programmed for yourself, so if it sounds unfamiliar, I wouldn’t worry about it.
Yeah, I am trying to clear arrays etc on end of use. I’d also expect this kind of failure to start pushing out memory use correct?
How many socket instances and shell instances do you have? If this is increasing (even slowly), it could be the framework spending more time polling.
Could be a loop that has bounds that grow over time. And get called often
It may not be noticeable if you were using WeakRefs. But I am talking out infinitely growing arrays. The problem with these messaging systems is that people often forget to remove the targets from the messaging arrays. So in the beginning, it only has to loop over 100 items, but as time goes on and targets are added, you have 1,000, 10,000 or 100,000. If you don’t clean up periodically, the loop itself becomes the problem because the oldest items are the most likely candidates to be gone, and you’re always traversing the entire array.
Thanks all
I’ll double check my arrays again tomorrow and report back.
I’m guessing I can just add some debug logic to check the size of my arrays periodically and report.
I use an array for queues, as follows:
myqueue.add (item) // adds item to end of queue
then for treatment:
while (myqueue.LastIndex>-1) // as long as the queue is empty
nextitem = myqueue (0) // next item to treat
myqueue.RemoveAt (0) // take it off the queue
// treat nextitem here
wend
And I still don’t understand why
A/ They did it at all, since
B/ It works out slower. Wasn’t the WHOLE POINT of Direct2D and 3D to hit the hardware and optimise graphics display on Windows?
If the speed of additions are faster than removals the app gets slower over time because the number of items to rearrange will grow. Removing items from the top is fast, from the base is very costly. One trick system programmers do for situations of just known peaks of accumulation followed by emptying is doing a circular queue (or buffer), the array is fixed, just the contents changes, and maintaining infos about the real size of the queue and where it starts currently. For uncontrolled growth situations it would lead to a “buffer overflow”. No system can get an uncontrolled memory use situation, if one has it, the system is broken.
You guys are thinking too much in terms of memory, and the problem can be related to time. Xojo has limited time to take care of many tasks. If such tasks accumulates or some of them start to take more time, probably leading to accumulation, that MAY be the cause here.
idea
you could add a 1 second timer in window and blink it in ui, if the timer action not comes the app is somewhere lost in a method.
Blink=1-Blink
if Blink then vital sign
Intercomm takes time, shell sessions takes unknown time to end and even can fail (don’t now what the user is doing). Xojo is an one thread system sharing time with the user’s fibers. It is easy to slowdown things accumulating tasks, and even breaking the intercomm due to timeouts and buffer overflows.
An alternative to a ring buffer would be a linked list as the time to insert / remove elements wouldn’t be impacted by the size.