David Abrahams wrote:
on Fri Jul 04 2008, "Doug Gregor" <doug.gregor-AT-gmail.com> wrote:
On Fri, Jul 4, 2008 at 2:02 PM, troy d. straszheim <[EMAIL PROTECTED]> wrote:
I did some work on this:
http://boost.resophonic.com/trac/traash
Switched sqlite => mysql, added a few indexes, changed around the views so
as not to
render an entire 6k step build/test run at once. Seems a bit snappier.
Comments
welcome.
Wow. That's pretty cool, and it seems pretty snappy from here. Is
there a more library-centric view, rather than a build-runner-centric
view?
That is pretty awesome responsiveness. As Doug points out, we need to
figure out what UI we really need now.
Yeah, we've come full circle. So let's talk. I added a 'narrow to project'
selector, which allows you to see a summary for only one project, say,
serialization:
http://boost.resophonic.com/trac/traash?project=Serialization
(note the new 'narrow to project' selection widget at the top) which would
presumably be handy for library authors/maintainers. But there
isn't anything like this:
http://www.boost.org/development/tests/release/developer/summary.html
just yet. Want to think about that one a bit. Comments welcome.
Things have slowed down slightly. This thing is running on an old, old p4
desktop with 512M ram, and I have a bunch of build slaves running round the
clock
loading up the database. This all for stress testing. Builds starting from
clean take
about 7k individual steps, and we have a lot of projects that have empty or
incomplete
CMakeLists.txt, so say it is actually 10k steps. The database on that machine
now
has 215k rows in it, so the back of the envelope is telling me we can keep 21
builds in
memory, say the 2 most recent on 10 different platforms for one branch. I'm
there is plenty more
performance to be had just in cleaning up the code (the trac/genshi templating
engine seems a little sluggish, among other things). Factor in a modern
machine, and it
looks like this thing could stay nice and snappy with, say, most recent 4
builds * 8 platforms
* 2 branches. So afaict we're looking good performance-wise.
-t
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
