Hi Keith
I remember this setting existed back in the times of eDeveloper, but
since it was never documented for XPA versions, I assumed it had
been replaced by the mgdebug option.
I will try it.
Thanks
Avgerinos
On 29/10/2019 10:59 π.μ., Keith Canniff
wrote:
Avgerinos,
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
Keith
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.
Regards
Avgerinos
On 29/10/2019 6:55 π.μ., Frederik Soete
wrote:
Hi, Avgerinos,
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@...>:
Hi
Keith
Are you referring to the MSSQL Profiler? Because
the problem exists even with calculation-subtasks
that are not accessing any database
Regards
Avgerinos
On 29/10/2019 5:51 π.μ.,
Keith Canniff wrote:
Avgerinos,
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.
Keith
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.
Regards
Avgerinos
On
28/10/2019 9:14 μ.μ., Andreas Sedlmeier
wrote:
Hi Avgerinos,
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.
Best regards,
Andreas
|
