+1 as well, but we need to make sure we can actually identify performance regressions. I don't know if currently we can draw any conclusions from significant drops in benchmark performance.
+100 for benchmarking branches. I think there's a tangentially related GSoC (moving toward speed.python.org and being multi-interpreter), but I don't remember seeing a blog post announcing the accepted projects. Cheers, Dan On Jul 11, 2011 4:32 PM, "Alex Gaynor" <alex.gay...@gmail.com> wrote: > On Mon, Jul 11, 2011 at 4:29 PM, Antonio Cuni <anto.c...@gmail.com> wrote: > >> On 12/07/11 01:20, Maciej Fijalkowski wrote: >> > Hi >> > >> > I'm a bit worried with our current benchmarks state. We have around 4 >> > benchmarks that had reasonable slowdowns recently and we keep putting >> > new features that speed up other things. How can we even say we have >> > actually fixed the original issue? Can we have a policy of not merging >> > new performance features before having a story why benchmarks got >> > slower? >> >> I think we really need to have support for branches on codespeed. Then, we >> can >> have a policy that a branch can be merged only if none of the benchmarks >> slows >> down. >> >> I heard that someone is working on it, but nothing concrete AFAIK, so I'm >> considering to do the work by myself (although I would prefer to work on >> something more in the core :-/) >> >> ciao, >> Anto >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev@python.org >> http://mail.python.org/mailman/listinfo/pypy-dev >> > > Isn't there a GSOC on that? > > Anyway +1 from me, if there's a regression it needs to be fixed, or > reverted. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
