[Cython] Some small phase refactorings

[Gary Furnish]

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
>