Re: [Webmacro-devel] org.webmacro.util.Clock + Logging

[Marc P. <ma...@an...>]

On Wed, 29 Jan 2003 11:18:31 -0500, Eric B. Ridge <eb...@tc...> wrote:

>> # Enabling the clock thread makes logging timestamps more efficient, but 
>> introduces
>> # an extra thread.  It may be useful when using logging for performance 
>> metrics.
>> UseClockThread: false
>
> That's just it, it's not used for benchmarking per se.  It's used for 
> calculating the timestamp for log messages.  And on top of that, the 
> value returned isn't guaranteed to be 100% accurate.  Which means if you 
> were trying to profile stuff based on log timestamps (bad idea), your 
> numbers would most likely be skewed.

That's not what I meant though. I don't mean profiling based on timestamps - 
 I mean using a real profiling tool, but running with code with logging 
turned on. Perhaps a niche case. This would completely trash profiling, 
thus making it impossible to do any profiling with logging turned on. Given 
the usually quite low overhead of logging, this could be annoying.

> I'd like to just get rid of it completely.  In this day and age of 2.4gHz 
> hyper-threaded servers and JDK 1.4.1 and 500mHz FSB, I really can't see 
> how Clock.java is saving us that much more over "new Date()". Besides, 
> the real performance problems with java.util.Date are actually when you 
> try to format the output using SimpleDateFormatter (for which I've grown 
> my own that smokes SDF.  Be glad to contribute if it sounds interesting).

new Date() calls System.currentTimeMillis(). This is a always very slow 
call, as it requires native code.

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants