You still need to malloc() your memory; however I realize that the
allocator can be *really* fast here. But still, you give a lot of the
gain back during the mark-and-sweep phase, especially if you also
move/compact the memory.
As you said, the allocator can be really fast. Most advanced gc
On Tue, 28 Aug 2001, Sam Tregar wrote:
Well, there's the Perl 5 reference counting solution. In normal cases
DESTROY is called as soon as it can be. Of course we're all anxious to
get into the leaky GC boat with Java and C# because we've heard it's
faster. I wonder how fast it is when
On Tue, 28 Aug 2001 21:07:03 -0400 (EDT), Sam Tregar [EMAIL PROTECTED]
wrote:
On Wed, 29 Aug 2001, Jeremy Howard wrote:
The answer used in .NET is to have a dispose() method (which is not a
special name--just an informal standard) that the class user calls manually
to clean up resources.
On Tue, Aug 28, 2001 at 09:07:03PM -0400, Sam Tregar wrote:
Well, there's the Perl 5 reference counting solution. In normal cases
DESTROY is called as soon as it can be. Of course we're all anxious to
get into the leaky GC boat with Java and C# because we've heard it's
faster. I wonder how
Sam Tregar wrote:
On Wed, 29 Aug 2001, Jeremy Howard wrote:
The answer used in .NET is to have a dispose() method (which is not a
special name--just an informal standard) that the class user calls
manually
to clean up resources. It's not an ideal solution but there doesn't seem
to
be
On Tue, 28 Aug 2001 19:04:20 -0700, Hong Zhang [EMAIL PROTECTED]
wrote:
Normally, GC is more efficient than ref count, since you will have many
advanced gc algorith to choose and don't have to pay malloc overhead.
You still need to malloc() your memory; however I realize that the
allocator can
