On Tue, 2005-11-29 at 00:51 -0500, Sandy McArthur wrote:
Since my last update I've made some performance improvements and made
my composite object pool both serializable and cloneable.
I've improved the construction so that the internal List that holds
idle objects is either an ArrayList or
Since my last update I've made some performance improvements and made
my composite object pool both serializable and cloneable.
I've improved the construction so that the internal List that holds
idle objects is either an ArrayList or a LinkedList based on which
will give the best performance.
On Mon, 2005-11-14 at 19:34 -0500, Sandy McArthur wrote:
On 11/14/05, robert burrell donkin [EMAIL PROTECTED] wrote:
i had intended to sit down and analyse the code in detail. however, i
have given it a quick once over and it looks very interesting. i'm happy
with the general direction of
I made a small benchmark that tests single threaded throughput
comparing similarly configured CompositeObjectPool (COP) with
GenericObjectPool (GOP).
I've posted the results from a rather beefy HyperThreaded Pentium 4 3
GHz idle machine using Sun's 1.5 server JVM at:
hi sandy
i had intended to sit down and analyse the code in detail. however, i
have given it a quick once over and it looks very interesting. i'm happy
with the general direction of the code. i work best when i can create
patches for small issues as i go. this is difficult when the code isn't
in
On 11/14/05, robert burrell donkin [EMAIL PROTECTED] wrote:
i had intended to sit down and analyse the code in detail. however, i
have given it a quick once over and it looks very interesting. i'm happy
with the general direction of the code. i work best when i can create
patches for small
On Wed, 2005-11-09 at 13:43 -0500, Sandy McArthur wrote:
Currently Pool only depends on the CursorableLinkedList when using the
Generic[Keyed]ObjectPool classes. I'd like to see this go away for two
reasons.
First, because the size of the Collections jar (546K) dwarfs the Pool
jar (41K) and
On Wed, 2005-11-09 at 01:17 -0500, Sandy McArthur wrote:
In the past weeks I've been working on a new implementation for Pool
that I'm calling a Composite Object Pool (COP). I'm at the point where
I think I've implemented everything I think the pool should have and
then some. I would like
Any other feedback? See: http://sandy.mcarthur.org/pool/
Since I've sent the last email I've reworked the idle object evictor
code such that it generates the least amount of contention I think is
possible short of using util.concurrent locking. The new eviction code
has the following properties:
: comments requested for a new implementation
In the past weeks I've been working on a new implementation for Pool
that I'm calling a Composite Object Pool (COP). I'm at the point where
I think I've implemented everything I think the pool should have and
then some. I would like feedback on the code
Commons Developers List
Subject: Pool: comments requested for a new implementation
In the past weeks I've been working on a new implementation for Pool
that I'm calling a Composite Object Pool (COP). I'm at the point where
I think I've implemented everything I think the pool should have and
then some
Currently Pool only depends on the CursorableLinkedList when using the
Generic[Keyed]ObjectPool classes. I'd like to see this go away for two
reasons.
First, because the size of the Collections jar (546K) dwarfs the Pool
jar (41K) and it's a slightly more of a hassle to manage two libs vs
one.
In the past weeks I've been working on a new implementation for Pool
that I'm calling a Composite Object Pool (COP). I'm at the point where
I think I've implemented everything I think the pool should have and
then some. I would like feedback on the code and if the response is
favorable I'll submit
13 matches
Mail list logo
