Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.
 

Application slowdown when leaving simain.logxxx in code?


#1

I have a huge function to monitor.
I inserted lots of SiMain.Logxxx calls to monitor variables, functions calls, return values etc.
When I disable logging via si.enabled:=false, the calls are still made.
Are they are performance hit, and I would need comment them out when I do not want to use logging (which would be a pain with hundreds of calls)?
I ant it as flexible as possible. When a user encounter issues, which do not result in a crash, I want to enable logging, and send the user this special version to get a log from him, and when not used, I just want to disable logging, without commenting hundreds of calls out.


#2

Hello Guenter,

there is practically no performance difference between disabled logging and removing the entire logging code. The disabled flag is checked at the earliest possible moment (at the start of each log method), so there is no performance hit at all if you leave the log calls in your application. A typical log method looks as follows (pseudo-code):

[code]function LogMessage(…)
{
if (!this.enabled)
{
return;
}

// Do the actual logging
}[/code]

You can just leave the logging statements in your application. If your users encounter a problem, you can tell them to enable logging (via a SmartInspect configuration file or some option in your application, e.g.) to find the problem. That’s what we usually recommend.

Another option would be to have logging enabled and use the memory protocol (as opposed to logging to a file, for example) which offers the best performance. The memory protocol can flush its data to a log file on demand.

Regards,
Tobias


#3

I think I will go with a menu, where the user can set si.enabled to true or false (assuming I can turn logging on/off anytime during runtime).
It can happen that the application would freeze without reason, and I would not be able to flush the memory based logfile. In such a case, EurekaLog would also not be triggered, so the writing to file in “realtime” is the best solution in my case.
When logging is enabled, performance is not that important at this specific moment.


#4

Sounds good. Yes, you can simply turn on/off logging at runtime, so that’s probably the best option in your case.

Regards,
Tobias