I'm having issues. You're telling me that the cost of calling a subroutine that returns a $dbh is overshadowing both the cost of creating the $dbh as well as the cost of whatever you're doing with that $dbh? That's not passing the sniff test.

In general, I find that optimizing the database provides a benefit/cost¹ that's at least 10x greater than any Perl optimization. For example, if you have something like:

my $sth = $dbh->prepare_cached("SELECT foo,bar from table where id = ?
+");
for my $id (@ids) {
    $sth->execute( $id );
    my @results = $sth->fetchrow_array;
    $sth->finish;
}
[download]

You'll gain a significant speedup rewriting it to:

my $placeholders = join ',', ('?') x @ids;
my $sth = $dbh->prepare_cached(
    "SELECT id,foo,bar from table where id IN ($placeholders)",
);

$sth->execute( @ids );
$sth->bind_columns( \my ($id, $foo, $bar ) );

while ( $sth->fetch ) {
    # Put values somewhere
}
$sth->finish;
[download]

That's both taking advantage of the best way to handle DBI as well as allowing the database to do more of the work. And, there's hundreds of similar restructurings that can provide up to 90% gains. The database will almost always be a major limiter of performance, especially if you're not doing it smart.

1. benefit/cost == The amount gained divided by (effort taken + effort to maintain). So, for example, if you were to replace all calls to a subroutine with the body of the subroutine, there would be a significant cost to do it (search+replace can do it, but testing's a bitch) plus a significant increase in maintenance (any change has to be applied with search+replace).