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

[Eric B. R. <eb...@tc...>]

On Wednesday, January 29, 2003, at 11:11  AM,=20
kea...@na... wrote:
> I remember this as well.=A0 I think it was Brian who pointed out that=20=

> using the System.currentTimeMillis() is really slow.=A0 But it seems=20=

> like managing a separate thread just for logging is a bit overkill.=A0=20=

> If this is primarily useful for benchmarking maybe we can have this be=20=

> a (yet another) configurable option.=A0 E.g.,
>
> # Enabling the clock thread makes logging timestamps more efficient,=20=

> but introduces
> # an extra thread.=A0 It may be useful when using logging for=20
> performance metrics.
> UseClockThread: false

That's just it, it's not used for benchmarking per se.  It's used for=20
calculating the timestamp for log messages.  And on top of that, the=20
value returned isn't guaranteed to be 100% accurate.  Which means if=20
you were trying to profile stuff based on log timestamps (bad idea),=20
your numbers would most likely be skewed.

I'd like to just get rid of it completely.  In this day and age of=20
2.4gHz hyper-threaded servers and JDK 1.4.1 and 500mHz FSB, I really=20
can't see how Clock.java is saving us that much more over "new Date()".=20=

  Besides, the real performance problems with java.util.Date are=20
actually when you try to format the output using SimpleDateFormatter=20
(for which I've grown my own that smokes SDF.  Be glad to contribute if=20=

it sounds interesting).

eric=