Re: Increasing delay of task-execution times


Thank you Frederik

I will try. Do you think transaction settings may affect execution of tasks that are not accessing any database tables?


On 28/10/2019 7:37 μ.μ., Frederik Soete wrote:
Hi, Avgerinos,

I have seen something like what you describe. In my case I was importing text files into memory tables, and the process of running my program seemed to take more and more time, although the text files in essence did not grow at the time.

In my case it turned out I had forgotten to adjust the transaction settings in some newly and hastily created tasks (e.g. the default 'Within Transaction) to something more reasonable. After some adjustments the tasks took a 'normal/expected' time again.

So, my idea is for you to check your tasks' transaction settings. Those can matter for performance.


Frederik Soete

Op ma 28 okt. 2019 17:49 schreef Avgerinos <mento@...>:
Yes, I thought of this already: tried boosting magic's priority but it does not affect execution time at all

On 28/10/2019 6:31 μ.μ., Jeroen Bos via Groups.Io wrote:

Just a thought, can it be that the program gets a lower execution priority or maybe that the program memory is replaced to the virtual memory?


Met vriendelijke groet / Yours sincerely



Jeroen Bos | Technisch Consultant (Technical Consultant)


Van: <> Namens Avgerinos via Groups.Io
Verzonden: maandag 28 oktober 2019 16:51
Onderwerp: [magicu-l] Increasing delay of task-execution times


Hi magicians

It's been 4 weeks that I 'm struggling with a weird behavior of XPA-runtime engine, noticed in all version versions from 3.3c and above, up 4.5a:

In a desktop app, there is a program executed by a timer event, once every second. This base-program is calling 20 resident sub-tasks (reading some data from database and making some calculations).
Some of the sub-tasks tasks read SQL2014 tables (on SSD drive), while the rest do only arithmetic calculations without accessing the database. 

During runtime, the whole process starts by taking around 350 milliseconds to execute, and this is quite acceptable for an event called every 1 second.
While executing the program keeps on slowing down: after 2 hours it will exceed the 1000 millisecond limit and will create an event-bottleneck.
Note that, this delay will not change if I stop and restart the event, or if I exit the program. The only way to reset back to normal execution times is to exit system and restart Magic.

While trying to locate the cause, I added time-logging code in all critical points. And this is where the strangest part comes:

  • Database accessing subtasks that were taking some time to execute (e.g. 15-ms), they still report the same execution time
  • Calculation subtasks with no access to database (exiting after a single record-suffix execution), report increasing execution times: they start from 0 ms and they gradually jump to 15-16 ms.
  • Note that these 15-16 ms seems to be the maximum accuracy I can get using the mTime() function for logging.

Some more remarks:

  • All subtasks are "non-abortable" (no events allowed)
  • I tried both options: resident or not resident tasks, and saw no difference
  • The behavior does not change whether executing from within the XPA-Studio (debug on or off), or directly with XPA-Runtime.
  • Tried many type of database locking schemes and saw no difference. Anyway the delay seems to happen more with non-database accessing subtasks
  • Tried replacing some of the SQL tables with memory tables, and saw no difference.
  • When tasks have already slowed down, the windows task-manager does not show any increase in CPU usage (always below 10%) or Memory usage (at least 40% of total memory free)

If anyone has similar experience or ideas, please let me know.

Thanks in advance


This e-mail may contain confidential and/or privileged information. If you are not the
intended receipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly

Deze e-mail kan vertrouwelijke en/of persoonlijke informatie bevatten. Als u niet de bedoelde
ontvanger bent, of deze e-mail per ongeluk heeft gekregen, breng dan de verzender
ogenblikkelijk hiervan op de hoogte en vernietig dit bericht.
Het kopieren, in de openbaarheid brengen of verspreiden van de inhoud van deze e-mail is ten
strengste verboden.

Ce courriel peut contenir des informations confidentielles et/ou privilegiees. Si ce courriel ne vous est pas destine
(ou vous avez recu ce courriel par erreur) svp, avertissez immediatement la personne qui a envoye ce courriel et detruisez le.
Toute copie non autorisee, divulgation des informations ou distribution du contenu de ce courriel sont strictement interdites.

Join to automatically receive all group messages.