RE: Proposed architecture changes to log4j for improved memory usage

[mwomack]

Chris, thanks for the submission.  I have not had a chance to review, but I
hope to soon.  Anyone else have comments?

-Mark

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 20, 2003 5:11 PM
> To: Log4J Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Proposed architecture changes to log4j for improved memory
> usage
>
>
>
> I sent an e-mail with this subject several months ago.  That e-mail
> described the changes I made to a Log4J 1.1.3 base for a customer I was
> working at.  There was alot of interest in the changes I described.
> Unfortunately the client would not allow me to release the code changes
> back to the open source group.
>
> I finally got around to refactoring these changes into 1.2.7.
> They are not
> fully tested and should be considered a prototype.  It does not
> contain all
> of the changes I described in my last e-mail.  This refactoring replaces
> the use of StringBuffer with Writer.  I tested with
> DailyRollingFileAppender.  Instead of writing an extra copy in memory to a
> StringBuffer it is written to the QuietWriter, which is backed by a
> BufferedWriter in DailyRollingFileAppender.  This is a win in speed(one
> less copy) and in memory(there is no StringBuffer).
>
> Here are a list of the files changed:
>
> Layout:  Adds "stream(LoggingEvent, Writer)" to replace
> "format(LoggingEvent)".  This is where the proposed change uses
> less memory
> by using a writer instead of a StringBuffer.
>
> PatternLayout, SimpleLayout, TTCCLayout, XMLLayout:
> The "stream" method looks very similar to format where
> sb.append(string) is
> replaced with out.write(string).
>
> HTMLLayout:
> Also adds a HTMLThrowablePrintWriter.  Better memory usage and shorter
> execution path than using ThrowableInformation.getThrowableStrRep(..).
> Questionable if using multiple appenders.
>
> PatternConverter:  Adds "format(LoggingEvent, Writer)" to replace
> "format(StringBuffer, LoggingEvent)" and "convert(LoggingEvent,
> Writer)" to
> replace "convert(LoggingEvent)".  Responsibility to output
> pattern falls to
> convert method.  Convinience method added to format String to a
> Writer, was
> done in "format" but now this is called from "convert" method.
>
> PatternParser:  Inner classes extending PatternConverter have new format
> method
>
>
> WriterAppender:  Changed to use the new "stream" method from
> layout passing
> in the QuietWriter.  Instead of using ThrowableInformation to get
> the stack
> trace, Throwable.printStackTrace is called directly.
>
> FileAppender:  Changed to delegate creation of QuietWriter to
> WriterAppender.  WriterAppender has a new PrintWriter set up at the same
> time and needs to be notified when the QuietWriter is created.
>
>
>
>
> If an appender needs a "String" from the layout it could send in a
> "StringWriter" and basically have the same end result as using a
> StringBuffer.
>
> If there's more interest in these changes I'm willing to talk about them.
>
> (See attached file: log4j_1.2.7_updates.zip)
>
> Chris Nokes
> Perficient, Inc
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Proposed architecture changes to log4j for improved memory usage

[Niclas Hedhman]

Agree. The fastest way of doing something is not to do it all. (Like to think 
that way regarding washing the dishes, cleaning the house, buy groceries... 
;o) )


On Friday 04 October 2002 10:43, Bauman, Nick wrote:
> Damn decimal point cadswallop. On your bike, Nick! :) :) :)
>  
> But the point remains "less is more". We opened up the doors one day on an
> app that was logging 13 pages per second. We got it down to something like
> 2 lines an hour. A lot more when things got wonky, as we needed it. 
>   -Original Message-  
>   From: Niclas Hedhman [mailto:[EMAIL PROTECTED]] 
>   Sent: Thu 10/3/2002 9:16 PM 
>   To: Log4J Developers List 
>   Cc: 
>   Subject: Re: Proposed architecture changes to log4j for improved memory
> usage 
>   
> 
>   On Friday 04 October 2002 06:58, Bauman, Nick wrote:
>
>   > Chris, your input is very helpful.
>   > 
>   > You say that per day, you're logging ~1 GB. What is that, something
>   > like, 1.15 MB per second? Isn't that too much?
>
>   
>   You just failed your 3rd grade math exam ;o)
>   
>   1,000,000,000 per day  / 24 hours = ~42 MB per hour
>   ~42MB per hour / 3600 sec per hour = ~11kB per second.
>   
>   IMHO, not a h**l of lot of data. Many websites exceeds that by just
> taking down ~150 char per request.
>   
>   --
>   To unsubscribe, e-mail:  
> <mailto:[EMAIL PROTECTED]> For additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]> 
>   
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Proposed architecture changes to log4j for improved memory usage

[Bauman, Nick]

Damn decimal point cadswallop. On your bike, Nick! :) :) :)
 
But the point remains "less is more". We opened up the doors one day on an app that 
was logging 13 pages per second. We got it down to something like 2 lines an hour. A 
lot more when things got wonky, as we needed it.

-Original Message-  
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]] 
Sent: Thu 10/3/2002 9:16 PM 
To: Log4J Developers List 
Cc: 
    Subject: Re: Proposed architecture changes to log4j for improved memory usage



On Friday 04 October 2002 06:58, Bauman, Nick wrote:
> Chris, your input is very helpful.
> 
> You say that per day, you're logging ~1 GB. What is that, something like,
> 1.15 MB per second? Isn't that too much?

You just failed your 3rd grade math exam ;o)

1,000,000,000 per day  / 24 hours = ~42 MB per hour
~42MB per hour / 3600 sec per hour = ~11kB per second.

IMHO, not a h**l of lot of data. Many websites exceeds that by just taking
down ~150 char per request.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




<>
--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Proposed architecture changes to log4j for improved memory usage

[Niclas Hedhman]

May I add to the "Date thread", that in my own "ancient proprietary" logging 
system (back in 97, I think), one of the best speed improvements were a small 
detail that is easy to forget.

Reviewing the log, it is important to know the time rather well, and that the 
order of the events are correct. But having a accurately formatted date field 
for each event may not be necessary.
I changed my logger so that the Date field was only formatted every 5 second, 
and had an additional field for millisecond since last format.

Major improvement in those days.

Niclas

On Friday 04 October 2002 02:05, Ceki Gülcü wrote:
> Hi Chris,
>
> Object reuse and optimizing memory usage was one of the themes I was
> seriously considering for future log4j releases.
>
> Your results are somewhat surprising. I knew memory usage could be
> improved but hadn't realized the extent...
>
> More comments below.
>
> At 10:42 03.10.2002 -0500, [EMAIL PROTECTED] wrote:
> >I am currently on a project using log4j for the first time.  We're using
> >1.1.3.  I had many concerns with the amount of transient objects created
> >during logging to a DailyRollingFileAppender.  I refactored log4j making
> >memory usage improvements that I think could be very useful to log4j
> > users.
> >
> >One recent test showed 350MB of transient memory created by log4j to log
> > 33 MB of data consisting of 33500 log entries; the number of transient
> > objects numbered in the millions and was uncountable by my tools.  The
> > layout pattern used was:
>
> Millions? Wow!
>
> >log4j.appender.R.layout.ConversionPattern=%d{MMM dd  HH:mm:ss,SSS} %t
> > % -5p %c - %m%n
> >
> >Without date formatting the total was ~275 MB.
>
> What happens with just %d (with nothing within the braces)? With %r?
> With no time information?
>
> >I appreciate the functionality offered by this framework but I find it's
> >disregard for memory consumption disturbing.  I refactored it and I can
> > now run the same test generating only 4 MB of transient data and 105000
> > transient objects for the same 33 MB data set.  The remaining 4 MB and
> > objects are JDK deficiencies and can't be overcome easily:
> >1)  The JDK's Thread class stores it's name as a char[].  Every time
> >Thread.getName() is called that char[] is converted to a String resulting
> >in 2 new objects, the String and it's associated char[].  I am going to
> > see if I can get a message through to the Sun folks to look at this.  Of
> > course, this framework could store the name once in a local variable on
> > first lookup, but this assumes the Thread name will never change
>
> We could circumvent calling Thread.getName() by caching the name of
> the thread. In general however, I deem it bad practice to go try to be
> smarter than the language.
>
> >2)  The sun.io.CharToByteSingleByte.convert method leaks a byte[1] every
> >time invoked.
>
> You must be kidding. :-)
>
> >This means for N messages logged, N * 3 objects are created from the JDK
> >when outputting Thread name and using a FileAppender.  I submit any other
> >transient object creation currently created by log4j is unwarranted and a
> >potential performance issue.
>
> Agreed. In log4j defense, I should say that log4j aims to be reliable,
> fast and extensible, in that order of priority. It is easier to be
> reliable with simpler but albeit less optimized code.
>
> >3) What if you knew logging a message would cost 1 KB of data for every
> >message sent no matter the size?  Well if you output the date using
> > default log4j functionality it does.  java.text.DateFormat.format
> > generates 30 transient objects using ~1 KB for every call.  I wouldn't
> > recommend to use DateFormat to stream dates, it is not built into it's
> > functionality to do it efficiently.  It is possible to output the same
> > information without using any transient objects.  From my tests, a large
> > % of the objects were created from date formatting.
>
> Do you mean SimpleDateFormat or just DateFormat. SimpleDateFormat is
> very inefficient. However, ISO8601DateFormat, DateTimeDateFormat and
> AbsoluteTimeDateFormat that ship with log4j and which all derive from
> DateFormat are supposed to be much more efficient. So I reiterate my
> question. Do you mean SimpleDateFormat or DateFormat?
>
> >LOG 4J Architecture Problems WRT Memory:
> >The problem with Log4J is that it uses a StringBuffer to format messages.
> >This means that the resulting formatted message is a transient object, it
> >is ready for GC as soon as the entry is logged.  This may highly degrade
> >system performance.  Not only does the message waste space, it creates
> > many objects in the GC graph and makes GC run longer - wasted CPU cycles.
>
> Sure, although recent JVMs are supposed to be much more efficient with
> respect to garbage collection.
>
> >One advancement I noticed in Log4J 1.2.6 was the use of a BufferedWriter
> >around FileWriters in FileAppenders.  This step saves the final formatted
> >StringBuffer 

Re: Proposed architecture changes to log4j for improved memory usage

[Niclas Hedhman]

On Friday 04 October 2002 06:58, Bauman, Nick wrote:
> Chris, your input is very helpful. 
>  
> You say that per day, you're logging ~1 GB. What is that, something like,
> 1.15 MB per second? Isn't that too much? 

You just failed your 3rd grade math exam ;o)

1,000,000,000 per day  / 24 hours = ~42 MB per hour
~42MB per hour / 3600 sec per hour = ~11kB per second.

IMHO, not a h**l of lot of data. Many websites exceeds that by just taking 
down ~150 char per request.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Proposed architecture changes to log4j for improved memory usage

[Chris . Nokes]

Nick,

I agree %100 that 1 GB a day is too much, and so would our ops group.  It's
not my decision, and apparently I don't have enough influence yet :)  It's
a system that went into production recently and the managers aren't willing
to turn off debug even temporarily right now.  It's not my code or my
system.  I'm just doing what I can to grease it.  If I can make the cost of
logging negligible it will make it that much easier to analyze memory usage
on the rest of the application.

Chris



   

  "Bauman, Nick"   

  
  k.com>   cc: 

           Subject:  RE: Proposed architecture 
changes to log4j for improved memory usage  
  10/03/2002 05:58 

  PM   

  Please respond to

  "Log4J Developers

  List"

   

   





Chris, your input is very helpful.

You say that per day, you're logging ~1 GB. What is that, something like,
1.15 MB per second? Isn't that too much?

We did once have an issue with too much logging bringing performance down.
To solve it, we added a feature in our logging component where we can raise
and lower logging levels on a per Logger basis on a running system. This
means we log almost nothing most of the time. We have to do this if we are
tp support ~10,000 concurrent users. If we think there's a problem, we can
turn up a single Logger to debug level and get more information.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thu 10/3/2002 2:35 PM
To: Log4J Developers List
Cc:
Subject: RE: Proposed architecture changes to log4j for improved memory
usage




 I'm glad to see the feedback and interest on the message I
posted.  I will
 try to start responding to specific questions early next week.

 For memory and object count I used JProbe 4.0.

 I very much appreciate the functionality of Log4J.  I am sold
on the API.
 Any changes I am proposing I believe do not interfere with the
current
 usage of the API or current performance WRT response time(it
might even
 improve however slightly).  I believe 0 transient object usage
is a worthy
 goal and would not be difficult to fit into the existing
framework.  The
 main premise is this, move the formatting of the response out
of a full in
 memory representation(StringBuffer) and stream it in fragments
to a
 destination via a buffer(BufferedWriter).

 On my project we have alot of GC.  The app does alot of
logging, ~1 GB a
 day and we are just starting to ramp up users.  Alot of the
garbage is not
 from logging.  The log4j changes I've made have really helped
the system
 overall because it is memory hungry to begin with.

 Chris



 --
 To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
 For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>



(See attached file: winmail.dat)--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>





winmail.dat
Description: Binary data

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Proposed architecture changes to log4j for improved memory usage

[Bauman, Nick]

Chris, your input is very helpful. 
 
You say that per day, you're logging ~1 GB. What is that, something like, 1.15 MB per 
second? Isn't that too much?
 
We did once have an issue with too much logging bringing performance down. To solve 
it, we added a feature in our logging component where we can raise and lower logging 
levels on a per Logger basis on a running system. This means we log almost nothing 
most of the time. We have to do this if we are tp support ~10,000 concurrent users. If 
we think there's a problem, we can turn up a single Logger to debug level and get more 
information. 
 
-Original Message- 
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Thu 10/3/2002 2:35 PM 
To: Log4J Developers List 
Cc: 
Subject: RE: Proposed architecture changes to log4j for improved memory usage




I'm glad to see the feedback and interest on the message I posted.  I will
try to start responding to specific questions early next week.

For memory and object count I used JProbe 4.0.

I very much appreciate the functionality of Log4J.  I am sold on the API.
Any changes I am proposing I believe do not interfere with the current
usage of the API or current performance WRT response time(it might even
improve however slightly).  I believe 0 transient object usage is a worthy
goal and would not be difficult to fit into the existing framework.  The
main premise is this, move the formatting of the response out of a full in
memory representation(StringBuffer) and stream it in fragments to a
destination via a buffer(BufferedWriter).

On my project we have alot of GC.  The app does alot of logging, ~1 GB a
day and we are just starting to ramp up users.  Alot of the garbage is not
from logging.  The log4j changes I've made have really helped the system
overall because it is memory hungry to begin with.

Chris



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




<>
--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Proposed architecture changes to log4j for improved memory usage

[Chris . Nokes]

I'm glad to see the feedback and interest on the message I posted.  I will
try to start responding to specific questions early next week.

For memory and object count I used JProbe 4.0.

I very much appreciate the functionality of Log4J.  I am sold on the API.
Any changes I am proposing I believe do not interfere with the current
usage of the API or current performance WRT response time(it might even
improve however slightly).  I believe 0 transient object usage is a worthy
goal and would not be difficult to fit into the existing framework.  The
main premise is this, move the formatting of the response out of a full in
memory representation(StringBuffer) and stream it in fragments to a
destination via a buffer(BufferedWriter).

On my project we have alot of GC.  The app does alot of logging, ~1 GB a
day and we are just starting to ramp up users.  Alot of the garbage is not
from logging.  The log4j changes I've made have really helped the system
overall because it is memory hungry to begin with.

Chris



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Proposed architecture changes to log4j for improved memory usage

[Shapira, Yoav]

Hi,
First of all - this was the most thought provoking message I'd seen on a
dev list for a long time, so thank you ;)

>Your results are somewhat surprising. I knew memory usage could be
>improved but hadn't realized the extent...

Same here.  But to preface, I value speed and reliability far far more
than memory usage.  Memory is cheap in the context I work in, so I might
be a bit biased...

>>One recent test showed 350MB of transient memory created by log4j to
log
>33
>>MB of data consisting of 33500 log entries; the number of transient
>objects
>>numbered in the millions and was uncountable by my tools.  The layout

Wow.  Huge numbers.  How did you measure transient memory, given that GC
was running?  What JVM was this, what GC parameters?

>>log4j.appender.R.layout.ConversionPattern=%d{MMM dd  HH:mm:ss,SSS}
%t

Hmm.  I wonder if %d by itself would be better.

>>disregard for memory consumption disturbing.  I refactored it and I
can
>now
>>run the same test generating only 4 MB of transient data and 105000
>>transient objects for the same 33 MB data set.  The remaining 4 MB and

Cool!  And thank you for posting the information.  The question is,
what's sacrificed to gain this memory improvement?  Did you benchmark
speed and/or CPU consumption before and after refactoring?

>>This means for N messages logged, N * 3 objects are created from the
JDK
>>when outputting Thread name and using a FileAppender.  I submit any
other
>>transient object creation currently created by log4j is unwarranted
and a
>>potential performance issue.

Potential performance issue, maybe.  But I'd rather have log4j create a
few (well-bounded amount, not millions) transient objects and work very
fast, relying on the garbage collector to collect them, than have some
tweaked for memory but very hard to understand and/or very complex
design.

>Agreed. In log4j defense, I should say that log4j aims to be reliable,
>fast and extensible, in that order of priority. It is easier to be
>reliable with simpler but albeit less optimized code.

Ditto.

>>3) What if you knew logging a message would cost 1 KB of data for
every
>>message sent no matter the size?  Well if you output the date using

1KB of data for how long?  If it's there for a few milliseconds before
the garbage collector takes away, I don't care at all.

>>is ready for GC as soon as the entry is logged.  This may highly
degrade
>>system performance.  Not only does the message waste space, it creates
>many
>>objects in the GC graph and makes GC run longer - wasted CPU cycles.

This *may* degrade system performance.  It depends on the GC
implementation and tuning.  For example, we have several large JVMs
(each one is long-running, heaps in GB, multiple log files, multiple
appenders of multiple types, tens if not hundreds of thousands of log
messages in the files), and yet we've found log4j to take almost no
appreciable memory compared to our apps.  Certainly not hundreds of MBs.
But we do a lot of tuning of the JVM runtime args for garbage collection
performance.

>>BufferedWriter.  It is cleaner, more efficient and is a first step
towards
>>0 transient object generation and 0 excess memory usage during
logging.

Very good suggestion.

>IMHO, the current approach is clean and very generic but optimal it is
>not.

That depends on the definition of "optimal" ;)  Which is an endless
argument, I know...  

But in my view:
- Disk space is dirt cheap
- Memory is cheap
- CPU cycles aren't very expensive
- A clean, easy to understand, easy to debug, easy to extend, generic
design is PRICELESS. 

I've seen the above over and over again.  We have to be careful to
strike the balance between optimizing too much and too little.

>>Objects that represent XML can be mapped to an ObjectFormatter and be
>>streamed to disk instead of first having an extra copy in memory.
This

Cool idea.  How do you know what objects represent XML?

>>created.  I propose the Date object become a member of LoggingEvent
where
>>it can be initialized once per logging event and date parameters
pulled
>>from a Converter.

What an interesting idea!  I'll have to think about that one.

>>One of the last pieces of memory to clean up was the LoggingEvents
>>themselves.  There is no reason why these objects can't be pooled.  I

Pooled how?  Isn't each logging event conceptually unique?

>I view these changes as a positive step to log4j.  I don't know how the

Possibly a HUGE positive step ;)

Thanks for posting everything!

Yoav Shapira
Millennium ChemInformatics


This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.

Re: Proposed architecture changes to log4j for improved memory usage

[Ceki Gülcü]

Hi Chris,

Object reuse and optimizing memory usage was one of the themes I was
seriously considering for future log4j releases.

Your results are somewhat surprising. I knew memory usage could be
improved but hadn't realized the extent...

More comments below.

At 10:42 03.10.2002 -0500, [EMAIL PROTECTED] wrote:
>I am currently on a project using log4j for the first time.  We're using
>1.1.3.  I had many concerns with the amount of transient objects created
>during logging to a DailyRollingFileAppender.  I refactored log4j making
>memory usage improvements that I think could be very useful to log4j users.
>
>One recent test showed 350MB of transient memory created by log4j to log 33
>MB of data consisting of 33500 log entries; the number of transient objects
>numbered in the millions and was uncountable by my tools.  The layout
>pattern used was:

Millions? Wow!

>log4j.appender.R.layout.ConversionPattern=%d{MMM dd  HH:mm:ss,SSS} %t %
>-5p %c - %m%n
>
>Without date formatting the total was ~275 MB.

What happens with just %d (with nothing within the braces)? With %r?
With no time information?

>I appreciate the functionality offered by this framework but I find it's
>disregard for memory consumption disturbing.  I refactored it and I can now
>run the same test generating only 4 MB of transient data and 105000
>transient objects for the same 33 MB data set.  The remaining 4 MB and
>objects are JDK deficiencies and can't be overcome easily:
>1)  The JDK's Thread class stores it's name as a char[].  Every time
>Thread.getName() is called that char[] is converted to a String resulting
>in 2 new objects, the String and it's associated char[].  I am going to see
>if I can get a message through to the Sun folks to look at this.  Of
>course, this framework could store the name once in a local variable on
>first lookup, but this assumes the Thread name will never change

We could circumvent calling Thread.getName() by caching the name of
the thread. In general however, I deem it bad practice to go try to be
smarter than the language.

>2)  The sun.io.CharToByteSingleByte.convert method leaks a byte[1] every
>time invoked.

You must be kidding. :-)

>This means for N messages logged, N * 3 objects are created from the JDK
>when outputting Thread name and using a FileAppender.  I submit any other
>transient object creation currently created by log4j is unwarranted and a
>potential performance issue.

Agreed. In log4j defense, I should say that log4j aims to be reliable,
fast and extensible, in that order of priority. It is easier to be
reliable with simpler but albeit less optimized code.

>3) What if you knew logging a message would cost 1 KB of data for every
>message sent no matter the size?  Well if you output the date using default
>log4j functionality it does.  java.text.DateFormat.format generates 30
>transient objects using ~1 KB for every call.  I wouldn't recommend to use
>DateFormat to stream dates, it is not built into it's functionality to do
>it efficiently.  It is possible to output the same information without
>using any transient objects.  From my tests, a large % of the objects were
>created from date formatting.

Do you mean SimpleDateFormat or just DateFormat. SimpleDateFormat is
very inefficient. However, ISO8601DateFormat, DateTimeDateFormat and
AbsoluteTimeDateFormat that ship with log4j and which all derive from
DateFormat are supposed to be much more efficient. So I reiterate my
question. Do you mean SimpleDateFormat or DateFormat?

>LOG 4J Architecture Problems WRT Memory:
>The problem with Log4J is that it uses a StringBuffer to format messages.
>This means that the resulting formatted message is a transient object, it
>is ready for GC as soon as the entry is logged.  This may highly degrade
>system performance.  Not only does the message waste space, it creates many
>objects in the GC graph and makes GC run longer - wasted CPU cycles.

Sure, although recent JVMs are supposed to be much more efficient with
respect to garbage collection.

>One advancement I noticed in Log4J 1.2.6 was the use of a BufferedWriter
>around FileWriters in FileAppenders.  This step saves the final formatted
>StringBuffer response from being copied into transient memory, a char[] the
>size of the StringBuffer, one last time in FileWriter.write(String).
>Instead it is copied into the BufferedWriter's reusable char[] which will
>call FileWriter.write(char[]).  This stops creating the message 3 times in
>memory, it is now only 2.  Can it be 1?  It is 2 times in memory because
>the current architecture requires the copying into the StringBuffer.  How
>about getting rid of the StringBuffer and directly appending to the
>BufferedWriter?  Instead of formatting to memory that is ready for GC as
>soon as logging is over, format it in reusable memory in the
>BufferedWriter.  It is cleaner, more efficient and is a first step towards
>0 transient object generation and 0 excess memory usage during logging.


It would be a