Performance

[iadonkey]

Hi!

this is not an issue, but only a discussion… At Zeugwerk we have a pretty similar logger and are currently implementing a fluent API for it (atm our API is not fluent) - in general our logging mechanism has some major differences to TcLog, because we don’t use a singleton pattern, but allow several loggers to be used in a single PLC and require logging into multiple log targets to be thread-safe.

I played around a bit on how to implement the fluent API for it and found that having the log level as the first call can improve the performance a lot. Our API, coming with Zeugwerk Framework 1.6, will look like this

_logger.AtInfo().LogMessage('I am a log message);
_logger.AtTrace().WithCondition(boolean1).Append('Number ').AppendInt(5).Append(' is alive').LogMessage('');
_logger.AtWarning().WithRisingTrigger(boolean1).LogMessage('boolean1 just got true');

having the log level as the „initiating“ call to the fluent API, has the advantage that a log message can be immediately discarded if the minimum log level as not satisfied, also if any „with“ condition is not met the message can be discarded. A discarded message doesn’t need any string operations, so besides the calls to the methods and an „if discarded then return“ the messages are for free.

What do you think of this?

[bengeisler]

Good morning! This sounds reasonable. It also gets rid of empty strings in the error etc. which bothered me stylistically for some time:

_logger.AppendString('...').AppendAny(myInt).Error('');

I'm a bit short on time right now but I'll look into it once I find some free hours.

Did you use a profiler to track this performance issue down? Which one did you use?

[iadonkey]

I just did some small tests with https://infosys.beckhoff.com/english.php?content=../content/1033/tcplclib_tc2_system/30963979.html&id= in our new implementation for the API. In general for logging just a string with any concatenation the fluent API has an additional call compared to a simple logger.Trace(…)

but I‘ll do some profiling later on with https://github.com/stefanbesler/twingrind , in our implementation we‘ll have both APIs anyway.