[Cython] local variable handling in generators

Stefan Behnel stefan_ml at behnel.de
Sun Jun 12 19:04:16 CEST 2011


Vitja Makarov, 31.05.2011 13:07:
> 2011/5/24 Stefan Behnel:
>> Vitja Makarov, 23.05.2011 21:33:
>>>
>>> 2011/5/23 Stefan Behnel:
>>>>
>>>> However, once we really know which values change between yield calls,
>>>> i.e.
>>>> which ones need to be stored away, it will actually be less expensive in
>>>> most cases. We currently pay the indirection penalty for each access,
>>>> even
>>>> read access, whereas the C compiler can then keep important variables in
>>>> registers and only write them back once per yield.
>>>>
>>>
>>> I think that all not NULL variables should be saved/restored inside yield.
>>> I can not really track changes only assignments.
>>
>> I mean "assignments" when I write "changes". When a variable is being
>> assigned to, we should assume that its value changed. Users can be expected
>> to be smart enough to avoid unnecessary assignments in most cases, there's
>> no need to put work into optimising them away automatically.
>>
>>
>>> for i in a:
>>>      yield i  # j is NULL here
>>> for j in b:
>>>      yield j # a, b, i ,j should be saved/restored
>>
>> Right. However, in general, we can expect that most variables will have been
>> initialised on a yield.
>>
>> We can still avoid storing away C typed variables that are not being used
>> later on, because they are not reference counted.
>>
>> And if the user sets 'a' and 'i' to None between the loops, they won't need
>> to be saved on the second yield either. But that's an optimisation, not a
>> requirement.
>
> What about copying C++ structs and objects with constructor (and/or
> overloaded = method)?
> That wouldn't work well.

I'd just make that an "unsupported feature" error for now. Remember, we are 
talking about C++ types used inside of generators here, which can only 
appear in newly written code. It's best to prevent users from doing that, 
at least until someone comes up with an actual requirement.

Stefan


More information about the cython-devel mailing list