[Biojava-dev] Re: [Biojava-l] Mutable Features - strand?

[Thomas Down]

Once upon a time, Matthew Pocock wrote:
> 
> What if ProjectionContext itself retained the non-property methods it 
> has (create/removeFeature, add/removeChangeListener, getShema, 
> project*), and then we have a design-pattern as follows for all of the rest:
> 
> In a given impl of ProjectionContext, we supply projecters and 
> unprjectors for properties e.g. projLocation, srcLocation or some other 
> sane prefixes. Then, the proxy code generator introspects the 
> ProjectionContext, and wherever it finds a proj or src method matching a 
> feature property, it delegates to that, and wherever it doesn't it 
> forwards the call on directly to the underlying feature.

That should certainly work.  Does mean that a new set of ProjectedFeature
classes need to be generated for each implementation of ProjectionContext
which is used, but I guess that's not too serious.

> One other issue is that most (all?) of the current projection impls are 
> creating new feature instances for the same underlying features each 
> time you view them. This makes some things hard. We could put some 
> standard feature caching (read weak references) into 
> ProjectedFeatureHolder to solve this. It's particularly anoying in the 
> GUI code.

What goes around comes around...

Older versions of the projection system *did* cache features,
but this also lead to problems, mainly memory-related.  The
(major) re-writes I did in 1.3 removed all the caching and
actually made the system run faster for the cases I tested.

What problems is this causing?  I don't think relyin on
identity of Feature objects is a great idea in general.  Can
you avoid it?

On the other hand, we've had some success since then with
WeakReference-based feature caching.  When I first used this
in BioSQL I did some ad-hoc benchmarking and found that
WeakReferences scaled reasonably well on Hotspot (at least
in 1.4).  This might not be true of some other VMs, but perhaps
we don't need to care about them any more.  Using these would
certainly make a caching ProjectedFeatureHolder a saner
proposition that it used to be.  I'm still not clear what the
advantages will be though, since I doubt it's actually going
to be substantially faster than re-creating the projections on
demand.


      Thomas