Currently, our C#, .Net 3.5 win app does quite a bit of Console.WriteLine() to keep ‘soft’ logs (not saved in files), which is both not entirely useful and probably a bit of a performance bottleneck, especially as its purpose is to do a bunch of calculations as quickly as possible.
I’ve just moved onto the team so I haven’t had time to profile an average running time, but it seems to me that it must be improvable by replacing the console output with something that is
- optimised for speed
- configurable at runtime, i.e. turnonandoffable
Configuration is great, but I have no idea if there would be any improvement, or degradation, in performance by switching to an equivalent amount of logging through a framework (Log4Net or other).
My gut tells me that having the same logging to the same output might be slightly slower in Log4Net as it’s essentially doing the same thing but having to go through another library. Is this correct or does it take some shortcuts to speed things up?
I would also think that skipping the console and writing directly to a log file would be faster (no buffer flushing, etc), as well as being saved for review/audit/posterity – so overall the best choice.
Does my thinking make sense – is this something I can confidently propose to the team lead? The only way I can reliably test this is to implement it, of course, but I was hoping I could back up my initial suggestion with others’ knowledge and experiences.
I hesit to answer, since you’ve given my answers yourself, but I’m starving for rep 🙂 …
In my experience, Console logging is the slowest option of all. I often started with console logging and was always surprised how much faster the program run, when I turned it of. I think, that you won’t even notice the (small) overhead of some intermediate framework, when you’re logging to the console.
I usually found it much faster to write to a file and use a dedicated log viewer software to watch it (sorry, I don’t have any software names at hand, but google should help you find a software).
There’s also an option to use eg. OutputDebugString and a viewing utility (sorry, again, no name), if you want to watch your log during runtime.
And of course saving logfiles for post-runtime-analysis is something, you might no longer miss after you started using it.
The augmented configurability is of course a benefit, personally I do not make much use of it besides globally turning logging on and off (ok, sometimes, I use two or three different trace levels if I want some messages also appear in production code).
So I think, your guts are right and I would suggest switching to some framework asap 🙂
Just one remark:
I would strongly suggest, not to disable buffer flushing. I flush my log buffers after every message. In case of a program crash, you won’t have any clues what went wrong, if you loose the last messages before the crash.