[Baypiggies] Question about breaking out of a loop

[Hy Carrinski]

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/
>