[Bioperl-l] Hilmar and Ewan debate SeqFeatures some more...
Ewan Birney
birney@ebi.ac.uk
Fri, 19 Jan 2001 21:10:16 +0000 (GMT)
On Fri, 19 Jan 2001, Hilmar Lapp wrote:
Hilmar. I agree with all your statements basically, but I'm still sticking
to my claims. I think we need to hear more feedback - I'd be really
interested in david's call on the defaultness of ->start not throwing an
exception.
We then might need to call in the supreme court here...
> Thomas Down wrote:
> >
> > Actually, my understanding is that the per-object overhead in
> > perl is pretty high, especially for objects implemented as
> > hashes. If you ever want to hold millions of SeqFeatures in
> > memory (a not unreasonable requirement, I'd suggest), a few
> > hundred bytes per location might come back with a vengence.
>
> Hmm. I guess I can't make a sensible comment on this. Anyone else out
> there who has experienced a performance drawback imposed by Perl's
> object handling (well, I know in fact it's not objects Perl handles
> ...)?
Oh yes ;)
Ensembl can trivially generate > 10,000 features in a modest sized
query. To get this to happen in any sensible way we have a packed C
struct. I would be against inisiting on two objects have to be present.
Of course having $seqfeature->location return $self for these cases could
really solve it. Therefore this is not a show-stopper for Ensembl, but be
aware that if we made this the default for Bioperl we would be doubling
our memory for feature-heavy queries, and I suspect suffering for it.
>
> If this problem is real, any chances this will be mitigated in
> upcoming Perl releases (5.6? 6.0?)? In general I hate having to adapt
> an object model to the limitations of a language ... :(
>
> >
> > Of course, this can probably be mitigated by implementing the
> > locations as C structs. Is this approach currently being
> > used in BioPerl?
> >
>
> Well, given the users on Win32 and Mac this is probably not an option
> for any module that is somewhat part of the core.
>
> Hilmar
> --
> -------------------------------------------------------------
> Hilmar Lapp email: lapp@gnf.org
> GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
> -------------------------------------------------------------
>
-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>.
-----------------------------------------------------------------