Also, it could be that more extensive caching was configured for the database in the old system. I have seen something similar once: I had cached a whole production database and later someone wanted to benchmark a new disk array. In effect the database was one big swap file, but smaller than the total RAM of the system. So as long as the database server wasn't started or shutdown, the shiny new disk array would be unable to outperform even an array of 1970s floppy disks using any SQL benchmark code you like! So it could be that the new system is doing disk I/O for database transactions and the old system was doing less or even NO disk I/O for the database transactions.

Also the same thing can be done for /tmp, i.e. in some production systems, /tmp is a virtual disk in memory, not a real one but your perl code coverage tools would never see the difference directly (one has to be careful what to infer).