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.
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
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.
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
On 28/10/2019 9:14 μ.μ., Andreas
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