On Jul 20, 2014, at 5:04 PM, Evan Huus <[email protected]> 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
