I have been using Devel::NYTProf for some time to squeeze performance out of a time-critical application. The application reads in a 4k x 4k image, resizes it (makes it smaller), runs a complex computer vision algorithm on the scaled-down data, outputs a bunch of data to text files and maintains a SQLite database. Some items I figured out along the way:
Doing "$new_pdl = zeroes($pdl);" is generally much slower than "$new_pdl = 0*$pdl", which is an issue if you are creating a bunch of large-image-sized workspaces. I haven't compared to (for example) $new_pdl = zeroes($pdl->dims); Watch out for automatic PDL hdr copying. Our input data is FITS so the piddles have a hdr, but hdrcpy is normally turned off. But PDL::Transform::map turns hdrcpy on before it exits (which normally makes sense), so I was spending a lot of time with Astro::FITS::Header copying the header of lots of small piddle slices. Explicitly turning hdrcpy off after PDL::Transform::map() returned saved a bunch of time. One subroutine went from taking 160 seconds per input file to 4 seconds. (That's not a typo--that one change sped that subroutine up by a factor of 40). I had previously posted about speeding up whichND on a 2D piddle of region values (see thread starting at http://mailman.jach.hawaii.edu/pipermail/perldl/2011-August/005311.html) The Devel::NYTProf Synopsis has a link to a screencast presentation by Tim Bunce that I found extremely useful and much easier than reading the POD. best, Derek On May 21, 2013, at 7:14 PM, Chris Marshall wrote: > To PDL Users- > > As part of the run up to the planned PDL-3.000 release > this Summer, I would like to challenge you to measure > the performance you get for your PDL applications. > > I recently profiled an image display application using > PDL with Devel::NYTProf and discovered that one > simple routine was using about 80% of the time leading > to a 10 frames/sec update rate. After optimizing the > code for the problem routine, the display update was > now 40 frames/sec. > > The point is that PDL is powerful, expressive, and fast > especially in reducing time to develop computational > perl applications and programs, but we could be losing > performance for no reason other than that we don't > know where it is happening. > > http://www.perl.org/about/whitepapers/perl-profiling.html > descibes the Devel::NTYProf module and has links to > presentations on its use. Give it a try---you may discover > a factor of 4X speedup yourself. If something is slowing > things down that could be improved, please let us know. > > Happy PDL-ing! > Chris > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
