On Fri, Feb 01, 2013 at 03:02:23PM -0800, Jacob Vanderplas wrote: > Goals #1 and #2 above don't seem to be a problem. I could make these changes > now, and actually speed up the ball tree by about a factor of 2 or so, while > making it a bit easier to understand and debug.
That's seems a net win. Clearly, #1 and #2 are probably to be included without any question. > 3) using typed memoryviews (cython 0.17+) rather than raw pointers for > ease of reading, maintaining, and debugging the code. > 4) adding the ability to specify distance metrics other than euclidean & > minkowski. > Goal #4 causes speed penalties because allowing compile-time switching of > the distance function means it can no longer be inlined at compilation. I guess you mean 'run-time' and not 'compile-time'. How many metrics are there? Would it be an option to single out Euclidean and have this one run fast, with a slower route for the others? > The net result is that code using memory views and flexible metrics is > ~2-3 times slower than the current code, and ~4-6 times slower than a more > optimized version of the code. Do you know how the slowdown breaks down between #3 and #4? Thanks a lot for working on this, Gaël ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
