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
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@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
participants (2)
-
Anders Hammarquist -
Miquel Torres