First things first, I would look at why a script is going kaboom when something is no longer used. Isolate the problematic design pattern and then replace it with something that is not so delicate. Under normal coding circumstances a loaded but unused module simply sits there, not bothering anyone. At worst it takes up a small amount CPU cycles to compile and a bit of memory to keep around, but that is about the cost of it.

For example, if the script is going kaboom because the module no longer exists on your system, maybe you want to replace use blah with something that checks first to see if the module is on the system before trying to load it. There are a large number of modules on CPAN that can be used to construct something like that. Among them: Module::Optional, Module::Pluggable, Module::Best, Module::maybe, Module::only, Module::Load::Conditional.

Trying to find loaded but unused modules is not an easy task, even in strongly typed languages like Java. At best you will get approximate results:

• Classes and modules can be loaded at runtime using a name created from a dynamically generated string or even a class name located in a user configuration file. There is no way to know in advance with certainty the full set of classes to be used during runtime.
• The class to which an object belongs is not necessarily the class that defines its methods. An object's methods can come from any of its super classes. In addition to finding anything that looks like a class name, you will have to navigate recursively to all the superclasses of that class and add them to the list of all classes in use.
• Identifying what looks like a class name is also at best an estimate, at least in Perl. Module files can contain multiple packages. The package names usually are the same as the module file, but not always. Objects and classes are defined by convention and are not hard coded into the language. Inheritance is defined using @ISA variable. Although it isn't good programming practice to do this, you can dynamically change the list of parent classes at runtime. Well written code will observe the convention of using new for an object constructor. But there is nothing stopping someone from using new for an entirely different purpose because "new" isn't a reserve word in Perl. Additionally, even good programmers need to have more than one constructor and sometimes name those additional constructors something other than new. For example, Test::Builder uses new to return a global test builder and create to return a freshly allocated test builder object. Sometimes people will use the input source as part of the name, e.g. "newFromFile", "newFromDB", etc.

If estimates are OK for your purposes, then you might want to take a look at PPI. However, make very sure you have a very good test suite that covers all code and considers all configuration files that might affect what modules are loaded. Otherwise, you may find you nixed a dependency that is in fact in use. Been there. Done that.

Best, beth