Re: [Wireshark-commits] buildbot failure in Wireshark (development) on Windows 8.1 x86

[Guy Harris <guy () alum mit edu>]

On Jul 20, 2014, at 5:04 PM, Evan Huus <eapache () gmail com> 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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe