On 31 Aug 2004, at 20:26, Werner Guttmann wrote:
On Mon, 30 Aug 2004 21:55:21 -0600, Bruce Snyder wrote:
Gregory Block wrote:
It would be nice if we included the oswego concurrency library and moved
to ReadWriteLock API for operations like this.
Also, sidenote: I've just done some perf analysis on our staging server
and found some pretty hefty inefficiencies in the TimeLimited cache.
(We use a low 10sec cache on some; larger on others)
- TickThread is reported as using an awful lot of CPU; - It seems to spend that time iterating. - Iterating through hashtables is a bad thing in general.
So, I've got two suggestions.
1) Move to ehcache implementation for our caches; it's a high-performance cache, and it's pretty good at this kind of stuff. Introduces a jar, but I'd almost rather have another jar than our current implementation...
or 2) I can provide a hacked up version of a conveyor belt
implementation of TimeLimited; we've got a conveyor belt API which
should be 1.2/1.3 compatible which we've hacked on just for the purposes
of getting a good performance out of large collections of time-limited
objects. Basically, the conveyor belt contains n containers; items
always go into the first container on the belt. Timer events go off
every (cache-time/buckets); when the timer event goes off, everything
moves over by one; a new bucket goes on to the front of the conveyor
belt, where new objects go, and one drops off the end,
which goes to a destructor and then to the garbage collector to gc.
When you ask for something out of the cache, you ask all the buckets on
the belt;
when something goes in, you verify that it isn't already in one of those
buckets.
It's quick, it's painless, it's low-cpu, and it makes disposal nearly
free. On the other hand, your time granularity isn't "exactly" n - it's
n to the nearest timer event. It's close, though.
Someone can decide whether to do 1, 2, or leave it the way it is. (I'd
prefer *not* to leave it the way it is.)
Gregory,
I would prefer the Oswego util.concurrent libarary. Yes, it is another
third party dependency but only prior to J2SE 1.5. It's actually
integrated into J2SE 5.0. We can get around this via the Ant build (e.g.
J2SE < 5.0 uses the Oswego util.concurrent library whereas J2SE => 5.0
uses the java.util.concurrent libarary (unless there are clashes with
old and new)) quite easily.
+1. Gregory, can you please open a new bug report.
Bug 1729.
+1 as well. And whilst we are talking about this, I think we should add the TimeLimited implementation by Stein as well (though this is JDK 1.3 and
above), but once again with Ant things can be done.
I think a separate cache implementation with a separate name is probably a better solution; entered as bug 1728.
Comments in both, both need comments from everyone else. :)
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
