Simon Kitching wrote:
> A push is quick, and cleaning up a callstack afterwards is normally done in
> fixed-time, regardless of what was on the stack. If params are passed in
> registers, it is even quicker. So IMO, SLF4J's approach is fine from a
> performance approach. Sorry if my mail wasn't
Hi Simon,
Comments below.
Simon Kitching wrote:
> Creating an object[] *after* the decision to log is made is no big
> deal. The overheads of actually logging a message are much higher, so
> passing the params is no longer significant. Only when one is created
> *regardless* of whether loggi
Joern Huxhorn schrieb:
> > Ceki Gulcu wrote:
> >
>
>> >> Joern Huxhorn wrote:
>> >>
>>
>>> >>> Simon Kitching wrote:
>>> >>>
>>>
The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params
is
slightly better, as it avoids the "
Ceki Gulcu wrote:
>
> Joern Huxhorn wrote:
>> Simon Kitching wrote:
>>> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is
>>> slightly better, as it avoids the "new Object[]" call. But for best
>>> performance, isDebugEnabled should be used anyway.
>>>
>>> Regards,
>>> Simon
Joern Huxhorn wrote:
> Simon Kitching wrote:
>> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is
>> slightly better, as it avoids the "new Object[]" call. But for best
>> performance, isDebugEnabled should be used anyway.
>>
>> Regards,
>> Simon
>
> Hi Simon.
>
> The abo
Hi Simon,
What you describe under [1] is called escape analysis. Under most
circumstances most code and most data is unused. This can be detected,
and some compilers actually do this. As I said, I am not sure the JVM is
capable of doing this. BTW, a runtime compiler such as hotspot has many
more o
Hi Erik,
You're right that the correspondence between bytecode and actual machine
instructions is not direct. And in fact, the machine instructions
could even vary during a program's run if the JVM is doing dynamic
optimisation.
But in this specific case,
(a) Whether the formatting parameters are
Hi Simon,
You should never confuse Java byte code with compiled byte code. I
understand there are a few superfluous byte codes, but in the end the
JVM determines how to compile it to CPU instructions. Unfortunately I am
not aware of what the JVM actually does with unused values. Does it do
escape
[EMAIL PROTECTED] wrote:
> It's nice to see that you were on top of this already.
>
> My only issue with your fix is that it can be ambiguous as to which comes
> first (params or exception). I'd much prefer putting the exception at the
> front of the method signature (as was suggested by anothe
Hi Joern,
Christopher White's sums the warts in the SLF4J API pretty well:
I did know that I can parameterize up to 2 parameters, which is
nice. But I also think that it is annoying to have to remember to
change the syntax once you hit 3+ parameters. Along with this, it is
also annoyi
Thanks,
Christopher White
Sr. Programmer
1-617-772-2403
[EMAIL PROTECTED]
Joern Huxhorn <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
04/24/2008 10:24 AM
Please respond to
User list for the slf4j project
To
User list for the slf4j project
cc
Subject
Re: [slf4j-user] Java 5 version of SLF
[EMAIL PROTECTED] wrote:
> I did know that I can parameterize up to 2 parameters, which is nice. But
> I also think that it is annoying to have to remember to change the syntax
> once you hit 3+ parameters. Along with this, it is also annoying to have
> to remember to change syntax when logging
Simon Kitching wrote:
> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params is
> slightly better, as it avoids the "new Object[]" call. But for best
> performance, isDebugEnabled should be used anyway.
>
> Regards,
> Simon
Hi Simon.
The above isn't the case for logback since ca
or the slf4j project
cc
Subject
Re: [slf4j-user] Java 5 version of SLF4J?
[EMAIL PROTECTED] wrote:
>
> Ceki,
>
> I do understand your reasoning, and thank you for your quick response.
>
> And since Logback natively implements SLF4J, its API will also not be
> chang
Hi guys.
My patch available at http://bugzilla.slf4j.org/show_bug.cgi?id=31
supports varargs without changing the slf4j API at all.
It would be included in maven like this
org.slf4j
slf4j-api-jdk15
1.5.0
compile
org.slf4j
slf4j-
Erik van Oosten schrieb:
> Christopher,
>
> As I wrote already on Feb 17:
> There is another aproach, as taken by http://code.google.com/p/log5j/.
> It is
> a wrapper around log4j. I wish they had made it for SLF4J!
>
> I am still waiting for someone to this for SLF4J. It should not be
pher White
Sr. Programmer
1-617-772-2403
[EMAIL PROTECTED]
Erik van Oosten <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
04/24/2008 09:50 AM
Please respond to
User list for the slf4j project
To
User list for the slf4j project
cc
Subject
Re: [slf4j-user] Java 5 version of SLF4J?
[EMAIL PROTECTED] wrote:
>
> Ceki,
>
> I do understand your reasoning, and thank you for your quick response.
>
> And since Logback natively implements SLF4J, its API will also not be
> changed to include any new JSE 5 features, correct? Nor will new method
> signatures specific to just Logba
Christopher,
As I wrote already on Feb 17:
There is another aproach, as taken by http://code.google.com/p/log5j/.
It is
a wrapper around log4j. I wish they had made it for SLF4J!
I am still waiting for someone to this for SLF4J. It should not be hard. I did
not yet find the time
24/2008 08:46 AM
Please respond to
User list for the slf4j project
To
User list for the slf4j project
cc
Subject
Re: [slf4j-user] Java 5 version of SLF4J?
Hello Christopher,
Users keep asking for varagrs [1]. However, as I stated at the time,
given that SLF4J is intended used by all sorts o
Hello Christopher,
Users keep asking for varagrs [1]. However, as I stated at the time,
given that SLF4J is intended used by all sorts of libraries, the
dependency graph between libraries and SLF4J can be surprisingly
complex. In particular, it would not be unusual for the dependency
graph to hav
Has there been any more discussion lately about updating the API to
support varargs and perhaps printf?
*** IMPORTANT
NOTE* The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brow
22 matches
Mail list logo
