[vtk-developers] Garbage collection slowness

[Brad King]

Hank Childs wrote:
> I ran the program I posted through "quantify", the profiling cousin of
> purify.  It looks like 48% of the cycles are spent in
> vtkGarbageCollector::Collect(vtkObjectBase*).

Okay, the GC is spending its time exploring the tiny reference graph of
each of the 25000 inputs.  The deferred collection will not help with
this, and in my tests is actually slightly slower probably due to
locality of reference problems.

I do have a fix for your case though.  See the attached modified version
of your example.  Here is what happens:

When you write

  norm->SetInput(outputs[i]);

the outputs[i] object is a stand-alone vtkDataObject with no producer.
All filter inputs are required to have a producer to make a valid
pipeline.  When there is no producer VTK creates a "vtkTrivialProducer"
automatically.  It comes with an executive, pipeline information object,
and a couple other pieces that all go into a small strongly connected
component of the reference graph.  Since you're doing that inside a loop
a separate such block of objects gets created for all 25K objects.

Instead you can manually create one vtkTrivialProducer and re-use it for
every input.  That greatly reduces the amount of work you're asking the
GC to do.  The attached code demonstrates this.  You can switch between
the old and new code by commenting out the #define USE_TP line.

I changed the "j" loop to only one iteration and produced these timings:

#undef USE_TP

  Allocating initial,  3.52777 seconds
  Calculating norm,  23.073 seconds
  Delete,  4.05667 seconds

#define USE_TP

  Allocating initial,  3.54613 seconds
  Calculating norm,  20.476 seconds
  Delete,  1.00634 seconds

> So, Berk: if I'm right that garbage collection is dominating, then the
> gameplan you're suggesting would be to reimplement Unregister() for each
> of the derived types of vtkDataObject to do their business without
> involving garbage collection?  Is that right?

We will separately investigate this.  I don't think that solution is as
simple as it seems.

-Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hrc_slow-fixed.C
Type: text/x-csrc
Size: 2342 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20080514/1965901f/attachment-0001.c>