Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inline iterator utility functions #676

Open
robertwb opened this issue Jan 15, 2009 · 3 comments
Open

Inline iterator utility functions #676

robertwb opened this issue Jan 15, 2009 · 3 comments

Comments

@robertwb
Copy link
Contributor

Filing this as it's an idea and I "need" it, but it is far out and really low priority.

Consider this snippet:

cdef inclusive_range(low, high):
    newhigh = high + 1
    return range(low, high)

Now, inlining this Cython-side could mean very much to performance. So the proposal is: If the iterator in a for-loop calls a cdef function, inspect whether there is a) only one possible return value outside of any branches, and b) if it is a Cython "magic loop function". If so, inline it in Cython.

(There's always the danger of this being too magic shrug)

Migrated from http://trac.cython.org/ticket/182

@robertwb
Copy link
Contributor Author

@dagss changed type from defect to enhancement
commented

@robertwb
Copy link
Contributor Author

scoder commented

I actually find this "too magic", as it handles a very special case that looks much more general to a user.

It would be better to a) have a more general typing step for functions based on their return value, and lacking that for now, b) allow something like

cdef xrange inclusive_range(low, high):
     ...
     return xrange(...)

@robertwb
Copy link
Contributor Author

@dagss commented

Ah, good idea. Alternatively a decorator, @cython.returnsmagiciterator or similar. I forgot that magicness can always be removed by adding explicit declarations :-) (complexity cannot though)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant