Okay, so I probably shouldn't be worrying about this anyway, but I've got some code that is meant to pass a (possibly very long, possibly very short) list of possibilities through a set of filters and maps and other things, and I want to know if my implementation will perform well.
As an example of the type of thing I want to do, consider this chain of operations:

get all numbers from 1 to 100
keep only the even ones
square each number
generate all pairs [i, j] with i in the list above and j in [1, 2, 3, 4,5]
keep only the pairs where i + j > 40

Now, after doing all this nonsense, I want to look through this set of pairs [i, j] for a pair which satisfies a certain condition. Usually, the solution is one of the first entries, in which case I don't even look at any of the others. Sometimes, however, I have to consume the entire list, and I don't find the answer and have to throw an error.
I want to implement my "chain of operations" as a sequence of generators, i.e., each operation iterates through the items generated by the previous generator and "yields" its own output item by item (a la SICP streams). That way, if I never look at the last 300 entries of the output, they don't even get processed. I known that itertools provides things like imap and ifilter for doing many of the types of operations I would want to perform. 
My question is: will a series of nested generators be a major performance hit in the cases where I do have to iterate through all possibilities?
"Nested" iterators amount to the composition of the functions that the iterators implement, so in general they pose no particularly novel performance considerations. 
Note that because generators are lazy, they also tend to cut down on memory allocation as compared with repeatedly allocating one sequence to transform into another.
How fast are nested python generators?