[Cython] Some more optimisations

[Robert Bradshaw]

On Feb 1, 2008, at 1:13 PM, Stefan Behnel wrote:

> Hi,
>
> Robert Bradshaw wrote:
>> On Feb 1, 2008, at 1:12 AM, Stefan Behnel wrote:
>>> - assignments replace the list content by their result of the
>>> analyse_types()
>>> for the right-hand side. This possibly requires taking into  
>>> account the
>>> current list of types, and it might mean we just append an  
>>> additional
>>> type
>>> possibility.
>>
>> analyse_types() won't be able to do much until we actually know  
>> what the
>> types in the expression are. I think the best we can do is build up a
>> table of "this type depends on these types in this way."
>
> So we'd build such a table for each statement?

More a list of assignments for every every variable.

>>> - branches (if/loops) collect the results of each branch and sort  
>>> the
>>> types in
>>> the expected order of probability - which might be arbitrary, but
>>> could be
>>> based on the number of occurrences over the branches.
>>
>> I'm not quite following here--how are branches/loops different  
>> than two
>> adjacent statements?
>
> I meant /after/ finishing the loop/if, when coming back to the  
> other block.
>
>   if cond:
>       l = []
>   else:
>       l = function()
>   return l[0]
>
> What is l here? Depends, but it's likely a list.

So, if function() (who knows where it's imported from) doesn't return  
a list, would that be an error. I was leaning towards having l be the  
most generic type possible (or, in other words, the most specific  
type that can handle all of the assignments).

>> I think for the first step, we should just leave functions (and class
>> members) as they are now--we can come back to them later but this  
>> will
>> make things much messier and less local (not to mention the issues of
>> cimporting functions and types from other modules).
>
> I agree. Getting the infrastructure in place and handling the easy  
> cases would
> be enough work for starters.

Very true, but interesting work.

- Robert