I’ve uploaded Devel::NYTProf 2.09 to CPAN.
If you’re using VMS the big news is that Peter (Stig) Edwards has contributed patches that enable NYTProf to work on VMS. Yeah! Thanks Peter.
For the rest of us there’s only one significant new feature in this release: NYTProf now includes a heuristic (that’s geek for “it’ll be wrong sometimes”) to handle modules using AutoLoader. The most common of which are Storable and POSIX. You may have encountered a warning like this when running nytprofhtml:
Unable to open '/../../lib/Storable.pm' for reading: No such file or directory
It’s a symptom of a deeper problem caused by AutoSplit, the companion to AutoLoader. The details of the cause, effect, and fix aren’t worth going into now. If you’re interested you can read my summary to the mailing list.
The upshot is that NYTProf now reports times for autoloaded subs as if the sub was part of the parent module. Just what you want. Time spent in the AUTOLOAD’er sub is also reported, naturally.
There is a small chance that the heuristic will pick the wrong ‘parent’ module file for the autoloaded subroutine file. That can happen if there are other modules that use the same name for the last portion of the package name (e.g., Bar::Foo and Baz::Foo). If it ever happens to you, please let me know. Ideally with a small test case.
The list of changes can be found here (or here if you’re a detail fanatic).
One other particularly notable item is that the
savesrc option wasn’t working reliably. Thanks to Andy Grundman providing a good test case, that’s now been fixed.
One thought on “NYTProf 2.09 – now handles modules using AutoLoader, like POSIX and Storable”
Tim, thank you for the upgrade. I have two feature requests.
1. It would be really great to be able to capture input/output parameters for some of the calls; I’d like to be able to specify what calls to track and then would get pairs of input/output parameters to be shown under the line (similar to the “# spent” line you have). Ideally, I’d be allowed to set up a callback to do normalization of input parameters to handle references, similar to what Memoize does. I understand that all that processing will impact execution time, but that’s okay. This is probably similar to what DashProfiler does and I’d like to see (potentially) better integration between the two. I’d prefer to see the results presented on one report, rather than capturing input/output myself and then trying to merge the two report together.
2. It would be also great to have a tree-view of the calls. I’d be able to set up a threshold and would see all (sub-)calls that (combined) took more time than threshold. I’d get a tree like:
Module A 5s
Module B 2s
Module C 1s
Module D 0.8s
and so on. All this in a collapsible/expandable tree ;) with links to appropriate places (like you already have in your table-based view). If this is not doable any time soon, it would at least be useful to highlight those calls that are above a threshold in the regular view (to make them stand out).
Thanks much for the great tool.
Comments are closed.