Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (developme
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sun, 20 Jul 2014 17:25:17 -0700
On Jul 20, 2014, at 5:04 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

> I don't really get this - it happens inconsistently that the "fast" allocator takes longer to run than the "block" allocator. The fast allocator does much less work, and runs substantially faster than the block allocator everywhere I've tested it.
> 
> I don't know what glib's timing mechanism is like, but is it possible the underlying machine is busy, so the wall-clock time is varying a lot?
> 
> I'm tempted to just disable the test, but that feels wrong.

Is there some reason not to test CPU time instead?  Yes, if, for example, the fast allocator ends up causing more page faults than the block allocator, even if it takes less CPU time, and if CPU time spent servicing the page fault doesn't get charged to your process or gets drowned out by I/O to service the page fault, a wall-clock time test might tell you something - or it might just reflect changes, during the time when the tests run, in memory pressure.