toggle quoted messageShow quoted text
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
- 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
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
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:
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.
give you a different prospective on what’s going
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
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
- 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.
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
Maybe this bug is back ? First check if you do
suffer from a memory leak.