[pypy-dev] Nightly Benchmarks

[Miquel Torres]

Hi Anders,
SQLAlchemy is problematic. there is a django-sqlalchemy project, but it is
still work in progress:
http://code.google.com/p/django-sqlalchemy/wiki/Roadmap

Otherwise, your DB design is valid. The simpler, the better.
One question: did you intend to keep a DB locally and then copy to the web
server backend or to store the data directly on the web server (
speed.pypy.org)?

About the DB design, while sufficient, I would probably add a couple of
things like version tags (for betas and final releases, for example), maybe
compile options (??). Why? because we want to be able to filter trunk
versions in every possible way.

In any case I want to discuss this a little bit more, because the DB needs
to be as complete as possible from the beginning. While the first version of
the visualization interface will be quick and dirty so that developers don't
have to wait months to have something useful (And only then will I design a
more powerful interface), I don't want to make big changes to the DB once we
start to regularly run benchmarks. That way the data can be safely stored
from the start.

Cheers,

Miquel



2009/10/1 Anders Hammarquist <iko at openend.se>

> Hello,
>
> In a message of Tue, 29 Sep 2009 11:31:21 +0200, Miquel Torres writes:
> >We agreed on a Django DB backend, and plot rendering by the browser, so we
> >need to talk about the way to store the nightly benchmark data into the
> DB.
>
> Hmm, I've already started to implement a DB store using SQLalchemy. Can
> Django use that? (it is in the repository at
> http://codespeak.net/svn/pypy/build/benchmark)
>
> >The end goal is to build a speed.pypy.org where you can compare all kind
> of
> >pypy versions to cpython and other python interpreters and other
> languages[...]
>
> Could prove interesting, and the DB structure I've got should be able
> to deal with that as well (it is quite minimal). The runner that is there
> is mostly useless for comparing different lanugagues though.
>
> >Can you please explain to me what you are doing in that area now?
>
> The intended next step is to interface a benchmark runner (of pypy trunk)
> with the database so the results will be persistent. I've been caught up
> in other (non-PyPy-related) work though. and if the database interface
> I've got is not useful, maybe I shouldn't do that.
>
> /Anders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20091001/102b4fdd/attachment.html>