Re: [boost] Some simple logging performance tests

From: Paul Baxter (pauljbaxter_at_[hidden])
Date: 2005-11-15 03:21:40

> Using GetTickCount and GetThreadTimes on Windows XP Pro, recorded time
> to execute some simple pieces of logging code in a loop. Divided by loop
> iterations to get time per iteration. This is a 3Ghz Pentium. Not sure
> how good these tests are, but here's the results:

Thanks Andrew, some useful results.

>
> results:
> elapsed ms thread time ms ns / call (GetTickCount)
> (GetThreadTimes) (in thread)
> cout 1329 421 42100
> enabled log 1469 453 45300
> cout "disabled" 15 15 15
> disabled log 531 531 531

I have been following all of the logging discussions and have taken at face 
value that disabled logs do not contribute a significant amount of time to 
the results, so I'm surprised about the disabled logs scenario being far 
worse than a disabled cout.
>
> Here's a little detail on tests

Could you post the source rather than the pseudo code, just to help speed up 
the investigations of others (I know the code is simple to write!)

In general, my concern with any of the logging libraries I've looked at, is 
their ability to provide a lightweight capability (speed and footprint) 
where needed e.g. in real-time embedded applications.

John seems to care about this, but I confess at present having spent only a 
couple of hours with the existing code, it's still not clear what bits are 
modular 'extras' and what bits I have to keep. (Though recent posts between 
John and Gennadiy have helped this understanding somewhat.)

I wanted to thank John, encourage him to continue with this essential 
library, but register my concern that the API probably needs to change (I 
agree with some of Gennadiy's comments) and the docs/testing need a fair bit 
more work (some of which really needed work before the review). I don't want 
to send the wrong message by putting in a negative review but equally I'm 
nervous about accepting things as is. I'm going to fence sit for now and not 
put in a review :)

I guess this is a wider decision than the logging library. Do I accept a 
library that I suspect ought to go through some API changes, or do I call 
for a subsequent mini-review but accepting things in principle. The 
implication is that accepting it now may imply future support for an API we 
may wish to deprecate.

Paul