On Dec 10, 2008, at 2:24 AM, Jelle Feringa wrote: >> I would call it doomed by design. If you use it from Python, I don't >> think >> you can beat direct iteration through __getitem__ *of the object* >> that you >> iterate over by introducing another level of indirection that >> introduces a >> method call. I tried islice() and it's still a bit faster than the >> class >> you presented. > > Given that islice does the same thing better definitely doomed ;')
You might be able to get speedups depending on your particular application. For example, if the think you're indexing into is slow, you could cache the result on the first lookup. Or, if it's a (small enough) int or floating point value, you could cache that and provide a nice C interface to it. But islice is about as fast as it's going to get and still be completely generic. >> Maybe you could give us some more insight into your actual use case, >> that >> might allow us to come up with better alternatives. > > Thanks, that's very kind. > Thing is that currently I'm working on sampling b-spline surfaces, and > compute the curvature of such a surface. > Basically that comes down to making a 500*500 grid of curvature > samples. > Computing the curvature is really quick ( call to a SWIG wrapped > object ). We must have different definitions of quick :). > My code looks like: > > for a in xrange(1, 500): > for b in xrange(1, 500): > do_curvature() > > When I place pass instead of do_curvature() I notice that the time for > such a loop is basically the same, which is why I'm interested in > moving the for loops to cython. The loops in Cython will be very fast. A 500x500 loop will be so fast it will be hard to measure. Calling a Python function or two inside the loop, however, will erase much of the benifit. > This is a pattern that is happens often in my code, hence it would be > lovely to make a function something like: > > loop_fast2d( do_curvature, (1,500), (1,500) ) > > What makes this pattern hard is that you would have to loop again > through the results, which reduces the time saved by a fast > loop_fast2d function by half. In Cython, the loop overhead is will be orders of magnitude smaller than the overhead of the function calls, so I don't think it'd matter. > So perhaps this pattern is more effective: > > loop_fast2d( do_curvature, do_result, (1,500), (1,500) ) > > What do you think? Is this pattern generic enough to be sped up in > Cython? The question should be "is this pattern too generic to be sped up in Cython." If, as your experiments indicate, the empty loop is almost as expensive as the do_curvature loop, then Cython can help you there. However, it can't speed up the 250000 calls to do_curvature. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
