For those who care, the problem is in how the filespace is managed. In the 0.x series, there is no concept of freed space. There is just the end of the file. So, when you do $db->{myhash} = {} (or anything that triggers the CLEAR() subroutine), only the index is currently wiped clean. The actual space is still used. Nothing in the 0.x series will actually mark that space as being usable.
For 1.00, I'm working on a freespace management algorithm that will attempt to reuse as much freespace as possible. So, in this case, it will remain the same size because the area that is now freed will be marked as being usable.
It will still leak, but the leak will be any contiguous filespace that couldn't hold something anyways. That minimum is currently 9 bytes for an internal reference, which is something like:
Without expensive relocations, there's no way to avoid this in any application that's based on a diskfile. Even applications like Oracle, MySQL, and Postgres eventually leak filespace. You just don't notice it.$db->{foo} = {}; $db->{bar} = $db->{foo};
In reply to Re: DBM::Deep dbfile size
by dragonchild
in thread DBM::Deep dbfile size
by zentara
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |