From: <web...@st...> - 2003-01-31 12:57:16
|
On Wed, 29 Jan 2003, Brian Goetz wrote: | | >I remember this as well. I think it was Brian who pointed out that using | >the System.currentTimeMillis() is really slow. But it seems like 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 still | as bad. | | Having a separate logging thread seems like a pretty practical | approach. It reduces IO latency in processing threads, reduces 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 logger | thread wake up only when there's stuff on the queue, and calculate 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. 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. 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 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 environemnt. Then I could have a "drop all templates" _method_ in the cache that forces reload. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |