[vtkusers] profiling vtk code

[Valerie R Coffman]

Steve,

I was able to use the callgrind tool, which is part of valgrind, without
recompiling vtk.  I found that it still reported subroutines that were called by
vtk routines and was able to figure out what I needed to know. (In my case
allocating memory for the point locater was the main hold up, so I reduced the
number of buckets.)  The downside is that it will likely make your software run
slower by at least a factor of 10, so you'll probably want to come up with a
reduced test case.  I also recommend kcachegrind to make sense of the stuff
callgrind will spit out.  

If you have access to a mac, there are some very cool profiling tools (Shark and
 Thread Viewer) built into the OS which don't require any compiler flags or slow
down your software nearly as much if at all.

Valerie


> Message: 10
> Date: Tue, 22 Apr 2008 18:12:05 -0400
> From: "Steve Chall" <stevec at renci.org>
> Subject: [vtkusers] profiling vtk code
> To: <vtkusers at vtk.org>
> Cc: tmrhyne at ncsu.edu
> Message-ID: <00d101c8a4c5$e9587460$55150e98 at Stevec>
> Content-Type: text/plain; charset="us-ascii"
> 
> I have some software built around vtk that's working very well, except that
> a central method is running forever.literally 4-7 hours.  I'd like to find
> out what's eating up the time and I'm pretty sure it's inside vtk code.  Is
> there a version of the vtk libraries that have been compiled so I can
> profile the code that's been built with them?  I really quail at the thought
> of rebuilding the vtk libraries with the -p option on.  I'm using g++ on
> Ubuntu Linux.  Thanks all.