Boost Interest :
From: troy d. straszheim (troy_at_[hidden])
Date: 2008-07-05 17:53:03
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 <troy_at_[hidden]> wrote:
>>> I did some work on this:
>>> 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.
>> 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
> 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:
(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:
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.