[Bioperl-l] Re: issues with _rearrange

[Ewan Birney]

On Fri, 20 Sep 2002, Aaron J Mackey wrote:

<<snip>>

Can I propose an


  (F) - Write a specific constructor, called like:

   $feature = Bio::SeqFeature::Generic->seqio_direct_new($start,$end,$tag_hash_ref);

   which is a "seqio optimised" constructor. The idea here is that SeqIO 
is allowed to "take a different route" from standard constructors and 
seqio_direct_new is allowed to do all manner of speed-magic - including 
filling in the hash directly outside of the get/set methods and - for 
example - directly using the tag_hash_ref built in the FTHelper object as 
the tag hash rather than adding things


   Ditto perhaps for PrimarySeq.


   Basically - can we write "direct_new" which are speed-optimised at the 
price of strict calling conventions and "insider knowledge"


   (caveat - how much stuff does Root::Object need intialised before it is 
happy, and if so... why...)




> 
> I like E.  I like E alot, but it's non-trivial; it slows compilation time
> a little bit, but is a big win during our many runtime loops ... this
> approach could be extended to other cases where we want to do something
> "directly" when we can, but not break encapsulation.
> 
> The drawback of E is that it would only be available if you go through the
> steps necessary to install optimizer.pm (which seem to include running at
> least perl 5.7.2 (or at the 5.8.0 stable release)).  But in an environment
> where speed would really matter, this could be a tremendous win.
> 
> Thoughts?
> 
> -Aaron
> 
> On Fri, 20 Sep 2002, Matthew Pocock wrote:
> 
> > Could you auto-generate <foo>_prety subs that just call
> > shift-><foo>(_rearange(@)), and have <foo> bypass _rearange totaly?
> > People who want performance would call <foo> with an args list, and
> > people who want nice names would call <foo>_prety with a hash. Perl
> > makes this kind of thing quite easy.
> >
> > Matthew
> >
> > Steve Chervitz wrote:
> > > --- Aaron J Mackey <ajm6q@virginia.edu> wrote:
> > >
> > >>On Thu, 19 Sep 2002, Aaron J Mackey wrote:
> > >>
> > >>
> > >>>my ($self, @args) = @_;
> > >>>my ($a1, $a2, $a3) = $self->_rearrange([qw(a1 a2 a3)], @args);
> > >>>
> > >>>becomes:
> > >>>
> > >>>my ($self, %args) = @_;
> > >>>my ($a1, $a2, $a3) = @args{qw(a1 a2 a3)};
> > >>
> > >>Before anyone jumps down my throat, I'm aware of all the -a1, -A1, A1, a1
> > >>options that _rearrange handles; things are never completely as simple as
> > >>we first believe them to be ;)
> > >>
> > >
> > >
> > > Another thing to try is exporting _rearrange from RootI so that it can be used
> > > as a class method, instead of an instance method, i.e., call it as _rearrange(
> > > ... ) rather than $self->_rearrange( ... ). This should improve performance.
> > >
> > > I've always been concerned about all of the overhead from _rearrange calls, so
> > > Aaron's suggestion seems reasonable to me. _rearrange is convenient, but maybe
> > > it's a little *too* convenient. Allowing this much flexibility in specifying
> > > method arguments is probably not necessary as many programmers and users are
> > > accustomed to precisely defined arg lists.
> > >
> > > Typically, our method PODs state what the allowable arguments are without
> > > stating that the hash keys are case-insensitive (and in some cases optional).
> > > So I'd bet that most users don't know this flexibility exists and we're taking
> > > a performance hit unnecessarily.
> > >
> > > Before deprecating _rearrange, I'd be interested to know how much the class
> > > function strategy improves performance, and how much not calling it at all
> > > further improves it.
> > >
> > >
> > > =====
> > > Steve Chervitz
> > > sac@bioperl.org
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > New DSL Internet Access from SBC & Yahoo!
> > > http://sbc.yahoo.com
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
> > >
> >
> >
> >
> 
> -- 
>  Aaron J Mackey
>  Pearson Laboratory
>  University of Virginia
>  (434) 924-2821
>  amackey@virginia.edu
> 
> 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
> 

-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>. 
-----------------------------------------------------------------