Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at