toggle quoted messageShow quoted text
This is not Magic Debug. It’s called the Magic Profiler and requires you to set a Windows Environment variable of MGPROF=1 for it to work and generates two files with performance information.
It will document every task executed and how long it took to run, plus lots of other stuff.
See my notes here: https://magicu-l.groups.io/g/main/message/188466?p=,,,20,0,0,0::Created,,MGPROF,20,2,0,24928383
From: email@example.com <firstname.lastname@example.org> On Behalf Of Avgerinos
Sent: Tuesday, October 29, 2019 1:46 AM
Subject: Re: [magicu-l] Increasing delay of task-execution times
Keith and Frederik
Yes, the magic debug log was one of the the first I though, but I did not have much luck at this time:
- The programs have to run for 1-2 hours (or to be called for 9.000-10.000 times) until the delay becomes significant, so the magic debug log becomes really huge and very difficult to manage.
- The magic debug log, gives you no way to focus on specific sub-tasks or to be activated after certain amount of execution time: You can select only specific execution levels and aspects, like gateway, program flow etc
- The actual information I managed to get from the magic debug log, was only confirming this increasing delay: like everything was gradually slowing down with no apparent reason. The flow was correct, the database was not slowing down etc...
Maybe, after one month of unsuccessful debugging, I should give it one more try. I need to add a new hard disk to my dev-machine only for hosting this debug-log. Plus I need to find a way to clean it up from all the unnecessary information.
On 29/10/2019 6:55 π.μ., Frederik Soete wrote:
I assume Keith means the magic profiling that can be activated via Windows environment variables: look up the "MGPROF" setting on this group, it has been mentioned some times before, and can give some insight into task calls, file opens/closes and their durations (milliseconds). Magic is able to write two such log files on closing a runtime process. Can be handier than writing your own logging.
Op di 29 okt. 2019 05:49 schreef Avgerinos <mento@...>:
Are you referring to the MSSQL Profiler? Because the problem exists even with calculation-subtasks that are not accessing any database
On 29/10/2019 5:51 π.μ., Keith Canniff wrote:
Have you turned on the Profiler rather than using the mTime function inside the application? The Profiler for the most part has almost no “drag” on the application, yet can track all the details you’re indicating.
Might give you a different prospective on what’s going on.
Thank you Andreas.
A memory possible leak was one of my first suspicions. But from what I can see in the task manager, only a very small increase in memory usage can be noticed after 200.000 event-calls, while the system still has plenty of memory available.
Another strange thing I noticed last night, was when I left a 2nd instance of magic running a different batch task at the same time, on the same host machine. This affected the behavior of the primary instance (the one running the timer-event):
- The event-program starts executing 30% faster, so it finally takes 30% more time to reach the critical delay I mentioned before (the event bottleneck).
- The mTime function, which I use for measuring the elapsed times, brings more accurate results: task execution times are reported with 1 ms increments instead of 15-16 ms increments returned otherwise.
Funny thing, is that I got similar results, when instead of running a parallel magic instance, I simply opened GoogleChrome and left it open, on a simple, not refreshing page.
I wonder whether this is an indicator that the problem relates to the way Windows are handling W32 apps and their execution-time allowance.
On 28/10/2019 9:14 μ.μ., Andreas Sedlmeier wrote:
Sounds like a memory leak in Xpa to me what you describe. Did you monitor memory usage of your process ? You can do that f.i. with Windows Performance Monitor (https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/using-performance-monitor-to-find-a-user-mode-memory-leak).
If you find out that you do suffer from such a leak you are however doomed. Magic is not open source. In the past Magic was leaking when you did something assign to Blob variables and in order to avoit this you had to update the Blob variable wiith NULL() - to force Magic to free the memory.
Maybe this bug is back ? First check if you do suffer from a memory leak.