I know nothing about mod_perl. Nothing at all! But...

• You have subtracted the time spent in DBI->Connect() from the time spent in DB_connect(), to see what you would gain by using a macro, haven't you?

  Because unless calling DBI->Connect(...) is extremely fast, using a macro to substitute that call for DB_connect() is going to make very little difference.

• If DB_connect() is really profiling as a significant proportion of the runtime for one or more of your functions (run modes?), then you must be calling it a significant number of times--like every time you need a $dbh

  Why not call it once at the start of each function and assign it to a local variable?

  I realise that this increases your exposure to the lose of your DB connection (slightly?) but given your use of RaiseError, you are already handling the possibility of errors on individual calls to DBI, this would be just one more potential error.

  Is the probability of the connection dropping within any given function (as opposed to between them) really so high?

Beyond that, if you really need a macro facility, there are several possibilities:

1. The highly deprecated and discouraged -P option (see perlrun)

   This probably wouldn't work with mod_perl?

2. The alternative to -P mentioned in perlrun, Filter::cpp.
3. The universally disliked possibility of a custom source filter using Filter::Simple or Filter::Util::call packages.
4. Using a preprocessor as a part of your "build" process. That could be the C preprocessor or a dedicated tool like m4.

Note: I'm not recommending you use any of these--indeed, from what information you've posted it is hard to see how a macro facility would benefit you in any significant way--but it is good to have the information available even if only that you can make your own mind up with good conscience.