buildbot status

[Charles Davis]

On Oct 8, 2011, at 2:30 PM, Dan Kegel wrote:

> On Sat, Oct 8, 2011 at 1:24 PM, Charles Davis <cdavis at mymail.mines.edu> wrote:
>> $ ccache -s
>> cache directory                     ~/.ccache
>> cache hit (direct)                 20226
>> cache hit (preprocessed)             140
>> cache miss                         10042
>> 
>> About a third of all the compiles are misses, but two thirds are direct hits. That's a fairly hot cache, but I think I can do better.
> 
> That just means you've only done two builds total, and the first build
> filled the cache, I think.
Actually, I've done lots of builds; that was after the first one to succeed.
> 
>> I obviously can't use ext4 because Mac OS only supports (officially) being installed on an HFS+ volume.
> 
> You're probably fine.  Next place to look for slowness is the tests.
> Which of the three groups of tests is the slowest?
advapi32:service (0:28) is the slowest test, followed closely by explorerframe:nstc (0:26).

shell32:shlexec (0:19), comctl32:status (0:17), kernel32:change (0:15), rsaenh:rsaenh (0:14), winmm:timer (0:12), cmd:batch (0:12), shell32:recyclebin (0:11), wininet:ftp (0:10), dxdiagn:provider (0:10), winhttp:notification (0:09), kernel32:console (0:07), comdlg32:filedlg (0:06), gdi32:font (0:06), kernel32:thread (0:06), kernel32:debugger (0:05), kernel32:heap (0:05), kernel32:profile (0:05), msctf:inputprocessor (0:04), and msi:action (0:04) are also slow. All the others take between 0 and 3 seconds to run.
> Can/should we parallelize more, or is there one test that's
> so slow it should be blacklisted?  Etc.
kernel32:change should definitely be blacklisted. It doesn't even pass anyway, because I haven't gotten around yet to implementing the functionality it's testing.

I'm willing to bet that at least some of these tests could be run in parallel.

Chip