[Evan Huus <eapache@xxxxxxxxx>]

On Sun, Jul 20, 2014 at 8:25 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

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?

I don't know how to do that cross-platform. Glib's timer is very convenient except for the fact that it measures wall time and not CPU time. Also, generally, wall time is the relevant metric as long as it is consistent; if I write code that takes very little CPU but is slow because it causes many page faults, I want the timer to reflect that because the actual user experience will reflect that (wall time more accurately reflects UX time).

 

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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe