As discussed in bug 102500, some parts of DOM/DOMWalk.html return a zero run time on the Chromium Win perf bot; comments in the test indicate that some tests run quickly ("This test runs in a short time. We loop a few times in order to avoid small time measurements.") The test should benchmark more work to have a meaningful runtime.
It is possible that zero is not a time, but a malloced size; I get this on Linux (Release): Running DOM/DOMWalk.html (35 of 113) RESULT DOM: DOMWalk= 0.170817563365 ms median= 0.171975207965 ms, stdev= 0.0042148697281 ms, min= 0.159652893669 ms, max= 0.178565660773 ms RESULT DOM: DOMWalk: JSHeap= 1570248.8 bytes median= 1569720.0 bytes, stdev= 8511.79536754 bytes, min= 1557376.0 bytes, max= 1584208.0 bytes RESULT DOM: DOMWalk: Malloc= 0.0 bytes median= 0.0 bytes, stdev= 0.0 bytes, min= 0.0 bytes, max= 0.0 bytes Finished: 8.950449 s
(In reply to comment #1) > It is possible that zero is not a time, but a malloced size; I get this on Linux (Release): > > Running DOM/DOMWalk.html (35 of 113) > RESULT DOM: DOMWalk= 0.170817563365 ms > median= 0.171975207965 ms, stdev= 0.0042148697281 ms, min= 0.159652893669 ms, max= 0.178565660773 ms > RESULT DOM: DOMWalk: JSHeap= 1570248.8 bytes > median= 1569720.0 bytes, stdev= 8511.79536754 bytes, min= 1557376.0 bytes, max= 1584208.0 bytes > RESULT DOM: DOMWalk: Malloc= 0.0 bytes > median= 0.0 bytes, stdev= 0.0 bytes, min= 0.0 bytes, max= 0.0 bytes > Finished: 8.950449 s Do you know why we're not encountering this problem in the downstream dom_perf? Or are we simply ignoring it?