On Fri, 2014-07-25 at 17:54 -0400, Tom Stellard wrote:
On Fri, Jul 25, 2014 at 11:28:19PM +0200, Bruno Jimenez wrote:
On Fri, 2014-07-25 at 12:46 -0400, Tom Stellard wrote:
On Sat, Jul 19, 2014 at 07:35:51PM +0200, Bruno Jiménez wrote:
This allows us two things: we now need less item
On Sat, Jul 19, 2014 at 07:35:51PM +0200, Bruno Jiménez wrote:
This allows us two things: we now need less item copies when we have
to defrag+grow the pool (to just one copy per item) and, even in the
case where we don't need to defrag the pool, we reduce the data copied
to just the useful
On Fri, 2014-07-25 at 12:46 -0400, Tom Stellard wrote:
On Sat, Jul 19, 2014 at 07:35:51PM +0200, Bruno Jiménez wrote:
This allows us two things: we now need less item copies when we have
to defrag+grow the pool (to just one copy per item) and, even in the
case where we don't need to defrag
On Fri, Jul 25, 2014 at 11:28:19PM +0200, Bruno Jimenez wrote:
On Fri, 2014-07-25 at 12:46 -0400, Tom Stellard wrote:
On Sat, Jul 19, 2014 at 07:35:51PM +0200, Bruno Jiménez wrote:
This allows us two things: we now need less item copies when we have
to defrag+grow the pool (to just one
On Sat, Jul 19, 2014 at 07:35:51PM +0200, Bruno Jiménez wrote:
This allows us two things: we now need less item copies when we have
to defrag+grow the pool (to just one copy per item) and, even in the
case where we don't need to defrag the pool, we reduce the data copied
to just the useful
This allows us two things: we now need less item copies when we have
to defrag+grow the pool (to just one copy per item) and, even in the
case where we don't need to defrag the pool, we reduce the data copied
to just the useful data that the items use.
Note: The fallback path is a bit ugly now,
