You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-dev@logging.apache.org by Tommi Mäkitalo <to...@epgmbh.de> on 2004/12/18 22:02:36 UTC
64-bit thread-id
Hi,
there is a problem printing thread-id on 64-bit:
log4cxx uses "StringHelper::toString(int, apr_pool_t*)" to convert the current
thread-id to a string. On my machine thead-id is 64 bit unsigned (unsigned
long), but int is only 32 bit and signed.
There is a elegant solution in c++: ostringstream. We can use ostringstream to
build the whole message. There is less hassle with formatting types then and
it is a portable solution.
What do you think?
Tommi
Re: 64-bit thread-id
Posted by Tommi Mäkitalo <to...@epgmbh.de>.
Am Sonntag, 19. Dezember 2004 01:19 schrieb Curt Arnold:
> > Just to fight at least a little for STL (I don't want to start a
...
>
> p.s. Can you modify the autogen or configure to set a macro in config.h
> to specify whether the RTL contains mbsnrtowcs and wcsnrtombs? (See
> transcoder.cpp for their use in case I mispelled the names).
done.
Tommi
Re: 64-bit thread-id
Posted by Tommi Mäkitalo <to...@epgmbh.de>.
Am Sonntag, 19. Dezember 2004 09:45 schrieb Tommi Mäkitalo:
> Am Sonntag, 19. Dezember 2004 07:11 schrieb Curt Arnold:
> > On Dec 18, 2004, at 6:19 PM, Curt Arnold wrote:
> > >> Just to fight at least a little for STL (I don't want to start a
> > >> flame-war
> > >> about STL): I created StringHelper::UlongToString-methods and
> > >> benchmarked it
> > >> against std::wostringstream. The result was, that for large numbers
> > >> (>INT_MAX, where your optimization don't catch), it took 2.3 seconds
> > >> to
> > >> format 1000000 with UlongToString and 1.5 seconds with
> > >> std::wostringstream
> > >> (including std::wostringstream-creation). For small numbers
> > >> UlongToString
> > >> took 0.5 seconds.
> >
> > For thread id it is probably more useful to output hex, since any
> > debugger would be unlikely to display a signed decimal representation
> > (plus it is very simple to implement).
>
> hex sounds good. When I saw my 64-bit thread-id I thought it looked
> somewhat funny. And yes - the implementation will get much easier. I will
> try that.
>
> Tommi
Here is the patch for logging thread-ids in hex.
I used basic_string::reserve here. Might improve performance when generating
logmessages also. I will check.
Tommi
Re: 64-bit thread-id
Posted by Tommi Mäkitalo <to...@epgmbh.de>.
Am Sonntag, 19. Dezember 2004 07:11 schrieb Curt Arnold:
> On Dec 18, 2004, at 6:19 PM, Curt Arnold wrote:
> >> Just to fight at least a little for STL (I don't want to start a
> >> flame-war
> >> about STL): I created StringHelper::UlongToString-methods and
> >> benchmarked it
> >> against std::wostringstream. The result was, that for large numbers
> >> (>INT_MAX, where your optimization don't catch), it took 2.3 seconds
> >> to
> >> format 1000000 with UlongToString and 1.5 seconds with
> >> std::wostringstream
> >> (including std::wostringstream-creation). For small numbers
> >> UlongToString
> >> took 0.5 seconds.
>
> For thread id it is probably more useful to output hex, since any
> debugger would be unlikely to display a signed decimal representation
> (plus it is very simple to implement).
hex sounds good. When I saw my 64-bit thread-id I thought it looked somewhat
funny. And yes - the implementation will get much easier. I will try that.
Tommi
Re: 64-bit thread-id
Posted by Curt Arnold <ca...@apache.org>.
On Dec 18, 2004, at 6:19 PM, Curt Arnold wrote:
>> Just to fight at least a little for STL (I don't want to start a
>> flame-war
>> about STL): I created StringHelper::UlongToString-methods and
>> benchmarked it
>> against std::wostringstream. The result was, that for large numbers
>> (>INT_MAX, where your optimization don't catch), it took 2.3 seconds
>> to
>> format 1000000 with UlongToString and 1.5 seconds with
>> std::wostringstream
>> (including std::wostringstream-creation). For small numbers
>> UlongToString
>> took 0.5 seconds.
>>
For thread id it is probably more useful to output hex, since any
debugger would be unlikely to display a signed decimal representation
(plus it is very simple to implement).
Re: 64-bit thread-id
Posted by Curt Arnold <ca...@apache.org>.
> Just to fight at least a little for STL (I don't want to start a
> flame-war
> about STL): I created StringHelper::UlongToString-methods and
> benchmarked it
> against std::wostringstream. The result was, that for large numbers
> (>INT_MAX, where your optimization don't catch), it took 2.3 seconds to
> format 1000000 with UlongToString and 1.5 seconds with
> std::wostringstream
> (including std::wostringstream-creation). For small numbers
> UlongToString
> took 0.5 seconds.
>
I'd like to keep it so that if someone wanted to create an STL
stream-free, log4j they wouldn't have to gut the infrastructure. I
would be very reluctant to introduce, for example, a new virtual method
on Layout where a parameter was a std::wostream. I don't have a
problem with localized use of STL streams where appropriate and
beneficial.
p.s. Can you modify the autogen or configure to set a macro in config.h
to specify whether the RTL contains mbsnrtowcs and wcsnrtombs? (See
transcoder.cpp for their use in case I mispelled the names).
Re: 64-bit thread-id
Posted by Tommi Mäkitalo <to...@epgmbh.de>.
Am Samstag, 18. Dezember 2004 22:30 schrieb Curt Arnold:
> On Dec 18, 2004, at 3:02 PM, Tommi Mäkitalo wrote:
> > Hi,
> >
> > there is a problem printing thread-id on 64-bit:
> >
> > log4cxx uses "StringHelper::toString(int, apr_pool_t*)" to convert the
> > current
> > thread-id to a string. On my machine thead-id is 64 bit unsigned
> > (unsigned
> > long), but int is only 32 bit and signed.
> >
> > There is a elegant solution in c++: ostringstream. We can use
> > ostringstream to
> > build the whole message. There is less hassle with formatting types
> > then and
> > it is a portable solution.
> >
> > What do you think?
>
> Creating an ostringstream has a surprisingly high creation cost and
> there have been at least some users that made reasonable cases for
> avoiding STL dependency where possible. I wrote a pretty simplistic
> 64-bit toString() equivalent in RelativeTimeFormat. Maybe if I brought
> that into StringHelper.
Just to fight at least a little for STL (I don't want to start a flame-war
about STL): I created StringHelper::UlongToString-methods and benchmarked it
against std::wostringstream. The result was, that for large numbers
(>INT_MAX, where your optimization don't catch), it took 2.3 seconds to
format 1000000 with UlongToString and 1.5 seconds with std::wostringstream
(including std::wostringstream-creation). For small numbers UlongToString
took 0.5 seconds.
Tommi
Re: 64-bit thread-id
Posted by Tommi Mäkitalo <to...@epgmbh.de>.
Am Samstag, 18. Dezember 2004 22:30 schrieb Curt Arnold:
> On Dec 18, 2004, at 3:02 PM, Tommi Mäkitalo wrote:
> > Hi,
> >
> > there is a problem printing thread-id on 64-bit:
> >
> > log4cxx uses "StringHelper::toString(int, apr_pool_t*)" to convert the
> > current
> > thread-id to a string. On my machine thead-id is 64 bit unsigned
> > (unsigned
> > long), but int is only 32 bit and signed.
> >
> > There is a elegant solution in c++: ostringstream. We can use
> > ostringstream to
> > build the whole message. There is less hassle with formatting types
> > then and
> > it is a portable solution.
> >
> > What do you think?
>
> Creating an ostringstream has a surprisingly high creation cost and
> there have been at least some users that made reasonable cases for
> avoiding STL dependency where possible. I wrote a pretty simplistic
> 64-bit toString() equivalent in RelativeTimeFormat. Maybe if I brought
> that into StringHelper.
I know you will tell that. I like the standard-library very much and I use it,
where I can. It would just be so easy to stream out all logmessages.
I quickly hacked it into log4cxx and my version now prints 64-bit thread-ids.
I looked at your 64-bit toString() equivalent. It looks really ugly, but I
fear that's the way to go.
Tommi
Re: 64-bit thread-id
Posted by Curt Arnold <ca...@apache.org>.
On Dec 18, 2004, at 3:02 PM, Tommi Mäkitalo wrote:
> Hi,
>
> there is a problem printing thread-id on 64-bit:
>
> log4cxx uses "StringHelper::toString(int, apr_pool_t*)" to convert the
> current
> thread-id to a string. On my machine thead-id is 64 bit unsigned
> (unsigned
> long), but int is only 32 bit and signed.
>
> There is a elegant solution in c++: ostringstream. We can use
> ostringstream to
> build the whole message. There is less hassle with formatting types
> then and
> it is a portable solution.
>
> What do you think?
>
Creating an ostringstream has a surprisingly high creation cost and
there have been at least some users that made reasonable cases for
avoiding STL dependency where possible. I wrote a pretty simplistic
64-bit toString() equivalent in RelativeTimeFormat. Maybe if I brought
that into StringHelper.