Originally posted by: Hawk Software
Any situation where exactly one instance of a class is desirable can be easily implemented as a singleton.
ReplyOriginally posted by: Amn
Hi :)
You indeed developed a powerful logging system. I did my own a while back, but that was intended for my custom TCP / IP server.
There were some things that i initially designed in your way, but later redesigned in favour of some ideas i had in mind. F.e:
1) Instead of logging text strings I shrunk the whole message format, and limited it to a raw date/time( number of seconds since Jan 1979 (system time routine result)), the id of the thread posting the message, event code (the message itself), and a binary list of parameters for that event, if any. That way any message I post is minimum (and usually) 3 words long. This keeps files VERY small, capable of storing a 2 months of hard server work in a 25 mb file, but it adds extra overhead of decoding log for us humans ;)
2) I didn't use any locks since the C++ runtime library locks the file access and that is all i needed, the rest of the class members were redundant (thread safe IN A WAY) by nature, i.e they used per-thread variables(thread DWORD a; f.e.) that never collide in a inter-thread simultaneous access, and thus do not need locks. I consider Mutex slow since it has to access the Win32 kernel mode. However your logging is inter-process safe , my is not, only between threads of the same application.
3) I developed a small and fast log decoding application that is able to read the log file on the fly, and show the log in graphical way. That means that the logging process does take responsibility of only logging the most basic but sifficient form of trace, while it is up to log decoder to decode the log and eat whatever CPU time it does. The goal was that the runing program should spend AS LITTLE CPU TIME as possible leaving traces of its work.
4) you should not use inline functions for the logging(unless the function itself is translated into 1-5 machine code bytes), for several reasons: a) Log functions are called VERY frequently (thats what they are for) and thus every inline substitution will grow your code quite considerably. Instead, usual function call is implemented at a speed of 50000000 times per second, which is negligiable comparing to the other code execution, and on the other hand keeps the code small.
5) I did not use any worker-threads helping of dumping the log, but, again, left it to the file buffers that flush automatically when filled up. YOu can make the buffer the size of approx. 1 Mb and this constitutes to appropriate time intervals for flushing, of course depending how fast the program does trace.
The above said is only meant as a suggestion, which are based on my own R&D in that particular area. I just hope our experience will grow based on this report ;)
I also don't like big CPP files and many headers hihihi ;)
Amn.
Reply