106882 2013-01-15 01:16:44 -0800 DOM/DOMWalk.html should be improved to have longer run times 2013-01-15 11:21:25 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 dominicc webkit-unassigned haraken noel.gordon rniwa oldest_to_newest 807089 0 dominicc 2013-01-15 01:16:44 -0800 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. 807100 1 dominicc 2013-01-15 01:21:59 -0800 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 807495 2 rniwa 2013-01-15 11:21:25 -0800 (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?