Is this a safe way to 'un'-require a module?

[stevieb]

Good day esteemed friends,

I'm writing a new module that will be long running. This module will have a function that requires code from another one of my modules (which loads 115+ other modules and dependencies), but this function will only be called on extremely rare situations so I don't want to use it.

I've written some mock-up (working) test code, and I'm just looking to see if this is a sane thing to do, and/or feedback on alternative approaches.

use strict;
use warnings;

use Symbol qw(delete_package);

my @pre_require = keys %INC;

print "Modules pre-require: " . @pre_require . "\n";

require Devel::Examine::Subs;
import Devel::Examine::Subs;

my @post_require = keys %INC;

# do something with imported module immediately after
# getting the post-require %INC count

...

print "Modules post-require: " . @post_require . "\n";

my $count = @post_require - @pre_require;

print "Additional modules loaded: $count\n";

for my $file (@post_require){

    if (! grep /$file/, @pre_require){

        (my $module = $file ) =~ s/\//::/g;
        $module =~ s/\.pm$//;

        delete_package $module;
        delete $INC{$file};
    }
}

__END__
Modules pre-require: 4
Modules post-require: 138
Additional modules loaded: 134
Module count post cleanup: 4

Thanks,

-stevieb

[tye]

The loaded modules aren't likely consuming much of import. Rather than prematurely optimize, either figure out how to measure the impact or find something actually useful to spend your time on.

I can see value in delaying the loading of such a large number of modules. But I find it hard to imagine how trying to unload them again would do anything other than consume more resources. The pages allocated to your process that your process doesn't touch are one of the least important resources in most situations are so are almost never worth trying to exert effort to optimize them.

For going from 138 modules loaded down to 4, it may even be more efficient to use "exec( $^X, $0, @ARGV );" to do that instead. And that is also less likely to cause breakage when you try to re-load the modules. Though, I wouldn't even bother with that unless I could find evidence of some real problem.

[jeffa]

I would wait until you know that this is causing an issue, premature optimization is the root of all evil. ;) Having said that, here's my take on the solution (given i did understand the problem correctly)

use strict;
use warnings;

if (shift) {
    eval "use Data::Dumper";
}

print Data::Dumper->Dump( [ 1 .. 10 ] );

The obvious problem with this solution is you lose features from Autoload --- this approach works best with object oriented packages that require instantiation but you can still work around non OO packages. Most of the time ... ... these kinds of concerns tend to open cans of worms. :/

[BrowserUk]

If it's that important: fork & use; do and die.

[stevieb]

I just had a birthday... I must be losing my mind in my old age :)