7.x: My application runs (very) slowly with EurekaLog
Posted by Aleksandr Alekseev on 02 February 2022 19:56
My application is fast when Eurekalog is disabled. But it runs significantly slower with EurekaLog enabled, like 20-50 times. For example, loading data without EurekaLog takes about 0.5 seconds, with EurekaLog - 50 seconds.
EurekaLog is an exception tracer tool. This means that EurekaLog's code is not executing in your application unless:
This means that EurekaLog can not possibly affect performance of your application unless your application is:
First, you need to find out which part of EurekaLog is slowing you down.
1. Start with checking if your code raises a lot of exceptions. For example, your or 3rd party code may use constructs like this:
Normally, you should see a debugger's notification about an exception. However, certain debugger's options could mask them (e.g. exception notifications could be disabled in settings). Please, go to your debugger's settings and:
Run your code again and watch for exceptions.
Alternatively, you can create a run-time log. Open the produced log file and look for EurekaLog's hooks being called.
2. If large amount of exceptions are not the issue then try to find out if your or 3rd party code is doing a lot of memory allocations. You can review your code to ensure it does not abuse the memory manager. For example, allocating a single array/cache is better than allocating millions strings or objects.
You can test if memory operations are causing the issue by going into EurekaLog's memory options and disabling the "Enable extended memory manager" option.
Important: do not keep the "Enable extended memory manager" option disabled. Disabling the option is only meant as a diagnostic tool. Please, refer to the "Solution" section below to learn about the possible ways to fix memory-related performance issues.
3. If memory operations are not the issue - try to find out if your or 3rd party code is spawning a lot of threads. Again, you can review your code to ensure that it does not abuse threads. For example, a single thread pool is much better to run short tasks than creating millions threads.
You can test if threads are causing the issue by going into EurekaLog's advanced options and setting the "Low-level injection hooks" option to "Allow for current module only" or "Disabled".
Important: do not permanently set the "Low-level injection hooks" option to anything other than "Allow all". Changing the option is only meant as a diagnostic tool. Please, refer to the "Solution" section below to learn about the possible ways to fix thread-related performance issues.
4. If threads are not the issue - check if you have a (very) large application (or a slow network drive) and have enabled the "Compress debug information" option. Storing debug information compressed means that EurekaLog has to unpack it before it can be used - which can take time if your application is very large.
5. If debug information is not the issue - check if you have a (very) large application (or a slow network drive) and have enabled the "Check file corruption" option. Enabling this option will cause EurekaLog to read your entire executable in order to calculate its checksum (CRC).
6. If CRC calculation is not the issue - check if you are running EurekaLog in debugging mode. Debugging is OFF by default and can be activated by:
See this article for more information.
Once you have determined which part of EurekaLog affects your code then you can fix it either by altering your code or adjusting EurekaLog.
1. If the performance issue is caused by exceptions:
2. If the performance issue is caused by memory operations:
3. If the performance issue is caused by threads:
4. If the startup performance issue is caused by debug information then do not compress it.
5. If the startup performance issue is caused by CRC calculation then turn off the corresponding option. There is no other way around it. Either you are checking your executable - in which case EurekaLog has to read it from start to end. Or you don't - in which case Windows will read/load your executable only as neccessary (e.g. progressive loading on demand).
6. If the performance issue is caused by debugging mode - simply turn it off. The run-time debugging is not supposed to be used for developing nor production. This feature exists for troubleshooting purposes only. It is not enabled by default and should be turned off immediately after solving an issue for which this mode was enabled in the first place.