[Cython] Some small phase refactorings

[Gary Furnish]

Well, clarifying what I meant a bit more, the *biggest* speed loss
anywhere is dictionary lookups.  If your going to use dictionary
lookups at object time, you lose most of the advantage of using cython
to compile cython.

On Sun, May 11, 2008 at 2:26 AM, Gary Furnish <gfurnish at gfurnish.net> wrote:
> Efficiency does matter to Sage though, and an O(1) overhead is very
> far from negligible.  Cython uses real C vtables, so there are
> absolutely no dict-based lookups involved with cdef class
> polymorphism.  -Infinity to any proposal that makes code slower.
>
> On Thu, May 8, 2008 at 11:50 AM, Dag Sverre Seljebotn
> <dagss at student.matnat.uio.no> wrote:
>>
>>> any replies than I guess that's an indication. I am actually a bit
>>> worried about how the use of decorators will impact the ability of
>>> Cython to compile itself into ultra-efficient C.
>>>
>> Efficiency doesn't bother me at all, and I have reasons! What the
>> decorators would do (does, in prototype code) is stuff the class name
>> and function into a dictionary at *class construction time* (or, without
>> metaclass support, at object construction time), i.e. a O(1) overhead
>> that is negligible even when running in the Python interpreter. During
>> tree traversal, it's just a dict lookup on class id and a dispatch to
>> the resulting function.
>>
>> If one were generating C++ objects then the classical visitor pattern
>> would be faster because real vtables are faster than dict lookups,
>> however Cython polymorphism is (if I'm not wrong, haven't looked at this
>> closely) dict-based anyway so it shouldn't make a difference.
>>
>> Here's another way to use 2.3 that might be acceptable:
>>
>> class WithStatementHandler(VisitorTransform):
>>    def handle_with(self, node): ...
>>
>>    matches = [
>>        class_match(WithStatementNode, handle_with)
>>    ]
>>
>>
>> It would end up as a dict of class -> function like the other approach
>> (but written like a list of objects because I'd like to leave a way open
>> up for other types of matches though).
>>
>>> It just didn't seem to add anything except another level of
>>> indirection, but that will of course eventually be needed. There is a
>>> lot of re-factoring that will need to be done. I've just got other
>>> obligations (general exam) to be able to put much time/though into
>>> this for the next two weeks or so :-(.
>>>
>> What it added was the capability to plug in new transforms after type
>> analysis, but before generation, on a module-wide basis, rather than
>> having the transform run once for each function.
>>
>> I didn't make that very clear; I suppose because you're right, it's real
>> value is in another layer of indirection -- but one that will be needed
>> and is useful during refactoring, and can allow "in-production"
>> refactoring, rather than applying it all at once.
>>
>> " The only problem that cannot be solved by another layer of indirection
>> is too many layers of indirection " :-)
>>
>> --
>> Dag Sverre
>>
>> _______________________________________________
>> Cython-dev mailing list
>> Cython-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/cython-dev
>>
>