Robotask and RAM memory management
Posted: Sun Dec 18, 2022 2:41 pm
V8.2
We have a complex program with many tasks which are successively launched with a loop. We are currently using V8.2.
Everything is OK.
We found this:
From 70 or 80 loops, the gui becomes erratic and inoperative, BUT, the tasks are executed WITHOUT problems until the hundredth loop.
Our conclusion
Our current procedure is to stop the tasks from the fiftieth loop, then to restart Robotask 8.2 with a batch file.
This procedure works without problems. The motto of the IT department is: "What works SHOULD not be changed!"
V9.3
We tested version 9.3 with the SAME procedures and tasks used with V8.2
We found this:
Between the twentieth or twenty-fifth loop, Robotask stops (kills!) ALL tasks in progress. This unplanned stop causes errors that are difficult to determine and correct.
Our conclusion
We understand that the management of the memory occupation in Robotask is corrected and improved. The goal is to keep the graphical interface running.
However :
- We are surprised to see a reduction in RAM usage before a restart of Robotasl V9.3
- Is Robotask V9.3 really a 64bit application?
We would:
- Obtain a warning that robotask is likely to reset, (like an internal variable) in order to correctly stop the tasks in progress, and restart Robotask with the dedicated function.
We have a complex program with many tasks which are successively launched with a loop. We are currently using V8.2.
Everything is OK.
We found this:
From 70 or 80 loops, the gui becomes erratic and inoperative, BUT, the tasks are executed WITHOUT problems until the hundredth loop.
Our conclusion
Our current procedure is to stop the tasks from the fiftieth loop, then to restart Robotask 8.2 with a batch file.
This procedure works without problems. The motto of the IT department is: "What works SHOULD not be changed!"
V9.3
We tested version 9.3 with the SAME procedures and tasks used with V8.2
We found this:
Between the twentieth or twenty-fifth loop, Robotask stops (kills!) ALL tasks in progress. This unplanned stop causes errors that are difficult to determine and correct.
Our conclusion
We understand that the management of the memory occupation in Robotask is corrected and improved. The goal is to keep the graphical interface running.
However :
- We are surprised to see a reduction in RAM usage before a restart of Robotasl V9.3
- Is Robotask V9.3 really a 64bit application?
We would:
- Obtain a warning that robotask is likely to reset, (like an internal variable) in order to correctly stop the tasks in progress, and restart Robotask with the dedicated function.