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?
Cheers,
Jakub.