On Tue, Jul 22, 2014 at 01:12:40AM +0200, darkjames-ws@xxxxxxxxxxxx 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.
