You have a variety of strategies available to you. Probably one of the most significant is to look at your actual queries and determine if you can optmize them by pushing all of a query into the owning class instead of allowing Class::DBI to span classes. This is a common and acceptable strategy. However, it does look like the bulk of your time is not spent on database access.

Right off the bat, we see that name_lc is taking a lot of time. That looks like a ridiculously large amount of time spent lower-casing a darned field name. Looking at the code, we see this:

use overload
        '""' => sub { shift->name_lc },
        fallback => 1;
                                                                      
+                                                     
sub name_lc { lc shift->name }
[download]

We have one too many method calls. Eliminating the overload would be great, but if we can't, how about:

use overload
        '""' => sub { lc shift->name },
        fallback => 1;
[download]

The only other place in the code that name_lc was being used was in Class/DBI.pm (and in only one spot). While it's nice to have a single point to lower-case the name, it's not as if we have exotic logic here, so if this solution seemed reasonable, perhaps submitting a patch to the Class::DBI list (assuming that you can demonstrate that this is a common case).

Still, I'd be concerned about these figures. The database is usually the bottleneck and that doesn't appear to be the case in your code.