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

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

On Friday, January 31, 2003, at 07:57  AM, Endre St=F8lsvik wrote:
> On Wed, 29 Jan 2003, Brian Goetz wrote:
>
> |
> | >I remember this as well.  I think it was Brian who pointed out that=20=

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

> managing
> | >a separate thread just for logging is a bit overkill.  If this is
> | >primarily useful for benchmarking maybe we can have this be a (yet
> | >another) configurable option.  E.g.,
> |
> | It certainly was slow at one point in the past.  I'm not sure if its=20=

> still
> | as bad.
> |
> | Having a separate logging thread seems like a pretty practical
> | approach.  It reduces IO latency in processing threads, reduces=20
> locking
> | contention for the logger, and generally seems more scalable.  Use a
> | dl.u.c.LinkedQueue which other threads could write to, and have the=20=

> logger
> | thread wake up only when there's stuff on the queue, and calculate=20=

> the time
> | once, at time of logging.
>
> Read about this in the o.apache.log4j package; a separate thread is a
> waste of pretty much anything when it comes to logging.

I don't have any evidence, but that's how I feel about it too.  I do=20
know that my own logging system is "fast enough", and it uses=20
System.currentTimeMillis() with a custom (and much faster) version of=20
SimpleDateFormatter.

> The clock thread thing is also a waste. Millis is fast on my linux =
box.
>
> IMHO, I think that WM shouldn't fire up _any_ threads w/o being asked.

I basically agree with this too.  Currently there's Clock.java,=20
TimeLoop.java, and PostponeObservable.java (if using the=20
GenerationalCacheManager).

Since the "clock" thread is used outside of the logging we can't easily=20=

delete it from CVS, but we can stop using it in the log system.  Would=20=

this be acceptable to everyone?  One (small) step closer to getting rid=20=

of it completely.

> Idea for 1.2, 2.0: the standard template cache-thing should be more
> intelligent. Why drop templates if there aren't any reason for it? I'd
> like to turn on "reloading" in a development context, and have it=20
> totally
> static for production envirnoments. For my part, I'd like to have the
> entire set of templates in RAM all the time in the production=20
> environemnt.
> Then I could have a "drop all templates" _method_ in the cache that=20
> forces
> reload.

What would this involve?  Maybe an ImmutableCacheManager that reads a=20
list of templates to pre-load from WebMacro.properties (or by walking=20
your template path)?  That could be nice for a production environment. =20=

It would basically be a cache that *only* provides pre-loaded=20
templates.  There'd be no need for threading or synchronization if it=20
were immutable.  Is this idea even sensible?

eric