If sqlite isn't caching already, the operating system is.

In real application I'm using postgres, but yes, you're absolutely right, 10000 additional requests can't take 15 seconds, I had to think about it, thanks. I ran it with Devel::NYTProf and have found that it spends a lot of time inside Class::Accessor::Grouped and inside various DBIx::Class modules, but not in DBI and DBD::SQLite. So I guess this overhead is caused by creating resultsets for 'Artist'. Pity.

Is this an optimization that makes sense to look for?

Sure. I'm reworking log processing application, that has serious performance problems, and hoped to replace current DB abstraction layer with DBIx::Class, as our current custom module is not very flexible and would require a lot of work after I fixed a DB scheme.

Concerning your last statement, generally I would agree with you, but in this case I know there the hot spots will be and I prefer to avoid them by spending some time on benchmarking and experimenting before I'll be limited by existing program structure. I think it will save me some time from these 95% in the end, so I could spend it here :)