[Biojava-l] ChangeSupport.java

Thomas Down td2@sanger.ac.uk
Tue, 5 Mar 2002 12:56:44 +0000


On Mon, Mar 04, 2002 at 10:06:27PM -0500, Peter Kharchenko wrote:
> Biojava guys (/girls?) ,
> 
>  I am using biojava for sequence alignment stats. I ran into a really 
> bad performance problem, which was apparently was caused by a rather 
> naive implementation of org.biojava.util.ChangeSupport class.  Rewriting 
> that class sped up my application by more then factor of 10.
>  I am sending you a copy of my implementation. I haven't changed any of 
> the methods (although some constructors are rather meaningless now), so 
> you should be able to just swap it in.


Hi...

Thanks for your work on this -- sounds like a very worthwhile
speedup.  However, there are two behavioural differences between
this code and the original:

  - It doesn't support hierarchical change types.  Listeners
    are only notified of events of exactly the requested
    type -- not any subtypes.

  - It keeps hard references to the listeners, rather than
    using the java.lang.ref package to maintain weak references.
    It becomes very easy to listen to a `global' object (for
    instance, the DNA Alphabet), and effectively make your
    object un-garbage-collectable.

I'm very curious to know exactly where your speedups are
coming from.  One possibility is that the WeakReference system
is just very inefficient (at least in some VMs), in which case
we need to re-think the system.

Another possibility I've just noticed is that the old implementation
makes a lot of calls to ChangeType.isMatchingType, in order to
support hierarchical ChangeTypes.  That method currently
constructs an Iterator.  If a lot of events are getting fired,
there will be a correspondingly large amount of object churn
of these Iterators.  It's possible to implement isMatchingType
without using the Iterator.  I'm tempted to try that and see
how much speedup we can get there, before changing the
behaviour of ChangeSupport.

Time for some benchmarking...

Thanks for bringing up this issue,

    Thomas.