Le 5 avril 2012 14:25, Vlad Niculae <zephy...@gmail.com> a écrit : > Hi everyone > > I have updated my proposal thanks to your excellent suggestions. > > I also pointed out the style of optimization that will be applied by linking > to my blog post on optimizing orthogonal matching pursuit code. Unfortunately > this will also flash the bug I introduced before everyone's eyes. I hope it > doesn't look so bad… does it? :) > > I have yet to point out obvious low-hanging fruits. What do you suggest? > > Do you think the proposal makes it clear enough that it's not just about > making stuff run faster, but also setting up a benchmarking system and making > sure things stay fast and that new code will be easily benchable?
I am ok with the fact of not giving the low hanging fruits in the GSoC proposal and use the results of the first part (the benchmarking step) of the GSoC to identify them in a principled manner. The performance bottlenecks are rarely where you expect them to be. Better use a profiler rather than a semi-educated guess. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Scikit-learn-general mailing list Scikit-learn-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
