[Baypiggies] Question about breaking out of a loop

[Jeremy Fishman]

Yes thank you Hy for pointing out f() function will not break early.  I am
not sure why I changed the implementation as I had intended f() to be a copy
of your for-loop from loop_fcn_v2() to demonstrate equivalency.

I believe g() generates exactly the values expected and no more.
  - Jeremy


On Tue, Jun 7, 2011 at 1:42 PM, Hy Carrinski <hcarrinski at gmail.com> wrote:

> I agree that this optimization is not critical. Premature optimization
> is certainly something that I try to avoid, and is an easy path to
> follow.
>
> My actual code has gone through a few rounds of refactoring and some
> optimization. This is question involves a specific area which my
> profiling has shown can introduce around a 10% decrease in runtime
> based only on eliminating this conditional. These rounds have involved
> effort to maintain and increase clarity. The computationally intensive
> functions actually make use of caching so they do not consume much
> time.
>
> I did not include many of these details in the original posting.
>
> By introducing the if statement, the runtime of the profiled actual
> code increases by around 20%. While that increase is not too
> important, the structure with the if statement does not seem right to
> me because it introduces the overhead whether or not the threshold
> option is exercised. Is there a more Pythonic way to introduce the
> break without the commensurate increase in overhead? By the way, I do
> think that this loop is the most appropriate place to introduce a
> threshold.
>
> w.r.t. Jeremy's recent interesting suggestions. I think that filtering
> on the generator may not actually result in StopIteration without
> computing the values. My actual generator makes a sequence of only the
> values that I care about. After writing it, I found a posting by Tim
> Peters from a few years ago at
> http://code.activestate.com/recipes/218332/ which uses an algorithm
> similar to mine (for the generator). But, please note that link is
> pretty far astray from the present questions.
>
> Thank you,
> Hy
>
>
> On Tue, Jun 7, 2011 at 1:06 PM, Dirk Bergstrom <krid at otisbean.com> wrote:
> > On 06/07/2011 12:40 PM, Hy Carrinski wrote:
> >>
> >> There is generator that yields tuples in a defined order into a loop
> >> that performs a calculation. I would like to provide an option to stop
> >> the calculation when the threshold is reached.
> >> The function in version 3 is pretty close to my current solution, but
> >> the functions combinations(), f() and g() are standing in for more
> >> computationally intensive functions.
> >
> > This seems like a perfect example of premature optimization.  You've got
> a
> > loop with two computationally intensive operations per cycle, and you're
> > worried about optimizing away a single if-equals check per cycle.  Will
> that
> > single if statement really make so much difference once you put the real
> > (and presumably much more time consuming) functions in place?
> >
> > --
> >       --------------------------------------
> >      Dirk Bergstrom           krid at otisbean.com
> >             http://otisbean.com/
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20110607/6cc67cdb/attachment.html>