[Tux3] Thinking about losing the dleaf free space vars
Shapor Naghibzadeh
shapor at gmail.com
Wed Oct 1 14:53:39 PDT 2008
I think at this point the tracking used/free explicitly will make
detecting bugs easier. Perhaps it should be left for now, and removed
later as an optimization.
Shapor
On Wed, Oct 1, 2008 at 2:07 PM, Daniel Phillips <phillips at phunq.net> wrote:
> Currently we have:
>
> unsigned leaf_free(BTREE, vleaf *leaf)
> {
> return to_dleaf(leaf)->used - to_dleaf(leaf)->free;
> }
>
> and the same result is produced by:
>
> int leaf_free2(BTREE, void *vleaf)
> {
> struct dleaf *leaf = vleaf;
> struct group *gdict = (void *)leaf + btree->sb->blocksize, *gstop = gdict - leaf->groups;
> struct entry *edict = (void *)gstop, *entry = edict;
> struct extent *extents = leaf->table;
> for (struct group *group = gdict - 1; group >= gstop; group--)
> extents += (entry -= group->count)->limit;
> return (void *)entry - (void *)extents;
> }
>
> Which is pretty efficient. I wonder whether it is worth maintaining
> the free/used variables in the dleaf at all? There are only two places
> where we actually need to know: in filemap.c, to decide whether we need
> to split the leaf before inserting new extents, and in btree.c to
> decide whether we can merge two leaves. In both cases we have just
> traversed the leaf contents anyway, and done most of the work of
> computing the leaf free space.
>
> Against this, we have a considerable amount of code for maintaining the
> free and used variables in the leaf during various operations. I have
> nearly convinced myself that we should err on the side of less code and
> get rid of the in-leaf variables.
>
> Regards,
>
> Daniel
>
> _______________________________________________
> Tux3 mailing list
> Tux3 at tux3.org
> http://tux3.org/cgi-bin/mailman/listinfo/tux3
>
_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3
More information about the Tux3
mailing list