comp.lang.c++

On Fri, 11 Apr 2008 21:17:47 -0500, Razii
wrote:

>Time: 24953 ms
>
>huh? Removing super.finalize(); it went back to Time: 172 ms

From IBM site:

Objects with finalizers (those that have a non-trivial finalize()
method) have significant overhead compared to objects without
finalizers, and should be used sparingly. Finalizeable objects are
both slower to allocate and slower to collect. At allocation time, the
JVM must register any finalizeable objects with the garbage collector,
and (at least in the HotSpot JVM implementation) finalizeable objects
must follow a slower allocation path than most other objects.
Similarly, finalizeable objects are slower to collect, too. It takes
at least two garbage collection cycles (in the best case) before a
finalizeable object can be reclaimed, and the garbage collector has to
do extra work to invoke the finalizer. The result is more time spent
allocating and collecting objects and more pressure on the garbage
collector, because the memory used by unreachable finalizeable objects
is retained longer. Combine that with the fact that finalizers are not
guaranteed to run in any predictable timeframe, or even at all, and
you can see that there are relatively few situations for which
finalization is the right tool to use.

If you must use finalizers, there are a few guidelines you can follow
that will help contain the damage. Limit the number of finalizeable
objects, which will minimize the number of objects that have to incur
the allocation and collection costs of finalization. Organize your
classes so that finalizeable objects hold no other data, which will
minimize the amount of memory tied up in finalizeable objects after
they become unreachable, as there can be a long delay before they are
actually reclaimed. In particular, beware when extending finalizeable
classes from standard libraries.