[Bioperl-l] SearchIO speed up

[Chris Fields]

I don't feel a pressing nature to keep it, but others will likely disagree. 

How hard would it be to implement hit(), query(), and other methods in HSPI
to return Bio::SeqFeature::Similarity objects directly instead of just
inheriting the methods?  In other words, only build and return the objects
when the user calls hit() or query()?

Chris

> -----Original Message-----
> From: bioperl-l-bounces at lists.open-bio.org [mailto:bioperl-l-
> bounces at lists.open-bio.org] On Behalf Of Sendu Bala
> Sent: Thursday, August 17, 2006 1:03 PM
> To: bioperl-l at bioperl.org
> Subject: Re: [Bioperl-l] SearchIO speed up
> 
> Sendu Bala wrote:
> > I am aiming to solve Project priority list item 1.2.1 "Improve
> > Bio::SearchIO speed...".
> [...]
> > More radical changes will make SearchIO even faster, eg.
> > Chris Fields and Jason (if I interpret the Project priority list item
> > correctly) have suggested an end to individual Hit and HSP objects,
> > which become just data members of a Result-like object. Ideally I don't
> > want to go down that route because we lose quite a bit of OO power; HSP
> > objects in particular make important use of inheritance
> 
> The most significant cause of slow-down is HSPI objects being
> Bio::SeqFeature::SimilarityPair objects. The main reason for that
> inheritance seems to be so we can have methods hit() and query() which
> give back Bio::SeqFeature::Similarity objects (which are
> Bio::SeqFeature::Generic).
> 
> Does anyone feel it is vital for HSPIs to be like this, or could they be
> simpler (eg. just return Bio::LocatableSeq objects for hit() and
> query(), with all other information available via direct HSPI methods)?
> 
> In one test case I can get a 3.5x speed up from that change alone.
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l