Presumably a slice operation should copy a reference to the Astro::FITS::Header object rather than deep copy it?
On Wed, May 22, 2013 at 9:18 AM, Derek Lamb <[email protected]> wrote: > 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 >
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
