On Tue, Jul 22, 2014 at 01:12:40AM +0200, [email protected] wrote: > > On Sun, Jul 20, 2014 at 08:04:30PM -0400, Evan Huus 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. > > Note that in simple allocator free all actually frees the data, > where in block data it's just got reinitialized (and wmem_block_gc() do free). > > So this test for simple allocator also checks how fast glib/system allocator > can do 8192 allocation/deallocation of 2MB block, > where block allocation do it just once. > > Any reason why we don't have same logic in all allocators?
Sorry, was wrong, please ignore this mail ;-) Should go sleep, now. ___________________________________________________________________________ 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
