Curt Arnold wrote:

No it is still helpful. I threw together the CVS stuff in a few hours to keep the conversation going and getting it to work and getting the API right were the priorities. Deriving log4cxx::basic_logstreambuf from std::basic_stringbuf was expedient to get things functional, but apparently std::basic_stringbuf has a significant fixed cost (at least in GCC's implementation).

Sorry for the delay. I've been a tad busy this week. Anyway, I finally have some somewhat puzzling results to give back.


I can't work on this today, but the following steps would hopefully get the CVS implementation performance close to yours for the no logging case:

1. Change the base class for logstreambuf to std::basic_streambuf and comment out the call to logger->log in logstreambuf::sync.

Okay, I basically did this. The CVS diff is here:

diff -r1.2 stream.h
30c30
< class basic_logstreambuf : public ::std::basic_stringbuf<Elem, Tr> {
---
> class basic_logstreambuf : public ::std::basic_streambuf<Elem, Tr> {
38c38
< ::std::basic_stringbuf<Elem, Tr>(::std::ios_base::out),
---
> ::std::basic_streambuf<Elem, Tr>(),
92c92,93
< str(),
---
> // str(),
> 0,


2. Run the no logging benchmark, hopefully it has dropped to near your implementations performance

So, this improved performance, but not nearly as much as I (and I'm sure you) had anticipated. Performance is now just under 1400ns per iteration (still about 30x slower than my version). I tried doing some profiling, but I need to build a profiled version of glibc to get some decent numbers (just over 70% of time is being spent in glibc). basic_streambuf does still have a lot of members to initialize on startup, and it does need a vtable and it has a non-empty virtual destructor (looking at it, one has to wonder why). Still, I'm more than a bit surprised by these performance numbers.


It is possible that if I upgraded to gcc-3.4 (which has a much more efficient iostreams implementation) that the performance might get more reasonable. I think though, that we should be able to come up with a logging stream that can perform reasonably well in the disabled case even if one has a lack luster iostreams library.

Thoughts?

--Chris

Reply via email to