setup gh-pages with this
usage: asv gh-pages [-h] [--no-push] [--verbose] [--config CONFIG] [--version]
Publish the results to github pages. Updates the 'gh-pages' branch in the
current repository, and pushes it to 'origin'.
optional arguments:
-h, --help show this help message and exit
--no-push Update local gh-pages branch but don't push
--verbose, -v Increase verbosity
--config CONFIG Benchmark configuration file
--version Print program version
@jreback we've got an extra step since we have multiple benchmarks per repository, but I've pushed https://dask.github.io/dask-benchmarks/ for now (see the https://github.com/dask/dask-benchmarks/tree/gh-pages branch). No judging my HTML skills :)
I'll leave this open and close it once I have a script that runs all the asv publish commands, and then updates the gh-pages branch.
They, that's pretty slick
Is there anything that needs to be done to maintain that page?
On Wed, Nov 2, 2016 at 9:25 PM, Tom Augspurger [email protected] wrote:
@jreback https://github.com/jreback we've got an extra step since we have multiple benchmarks per repository, but I've pushed https://dask.github.io/dask-benchmarks/ for now (see the https://github.com/dask/dask-benchmarks/tree/gh-pages branch). No judging my HTML skills :)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dask/dask-benchmarks/issues/3#issuecomment-258046671, or mute the thread https://github.com/notifications/unsubscribe-auth/AASszDExvHhnrS-ntrEwUNiZfPYgIkPBks5q6TgYgaJpZM4Kn0u- .
Once we have a stable set of benchmarks, the biggest thing is getting a dedicated machine to run the benchmarks for each new commit (a nightly cron job, similar to this). Is that something Continuum could help acquire? We'd need the actual machine instead of using a CI service since we want the runs to be comparable across time.
Yes, I suspect that Continuum could swing that. CC @seibert
Yes, what kind of machine would you like to run on? We have an 8 core Haswell system with 64 GB of RAM that we use for Numba testing. Would that work?
@seibert that would be more than sufficient, overkill probably :)
From here it looks like the most the biggest concern is having other heavy-load processes running at the same time.
Hmm, the typical load on that machine is zero, except when building Numba packages (average once every few days, but can be bursts of several times in a day) or when someone is doing manual testing.
Would it be fine to provision a fixed-size AWS instance to run benchmarks? Running a c4.xlarge (4 CPUs w/ 7.5 GB of RAM) for an hour once a day is pretty cheap.
Could we use biggie (internal continuum 48 core box)? I think it's mostly idle.
The cron job would need to run new benchmarks as well, see instructions in https://github.com/spacetelescope/asv/issues/278