In my humble, the best metric of how “fast and efficient” a particular package is, is determined by how easily and effectively it enables you to do what you want.   Never mind how “quickly” the CPU can move data around in memory, or how well the filesystem can do its job.   How fast can you get your programs written?   How much of the “heavy lifting” can you palm off to this-or-that Perl package?

“Huge” is a very relative term these days.   The laptop that I am using right now has four CPU cores, 6 gigabytes of RAM, and it has 1.5 terabytes of disk storage attached to it.   Is that “huge?”   It’s rendering a video while I’m talking, and its heart’s not skipping a beat.   Is that “slow,” or “fast?”   All I know is, when I set down to program the thing, that will take a very long time.   Fixing or rewriting a program takes even longer, and a lot more coffee.

I personally use XML::Twig most often, because it is, as you say, “beefy,” and therefore I know that it will pretty much accept any file out there and do anything I need to do with it.   But that isn’t speaking against, e.g. XML::Simple in any way whatever.   What you don’t want to do is to get partway into your project, using tool “A,” only to discover that there is a problem that you have, which the tool you selected cannot easily solve.   You don’t want to find yourself writing code to “make up the shortfall.”

So, before you make any selection, do some tests.   I actually have used Test::More techniques to quickly cobble-together some exercises that I can then throw at various example files, just to be sure that the tools and techniques that I’m planning to use will work, when the scenario is stripped down to bare-bones.   It is actually a very good way to do “proof of concept” experiments.

“Look before you leap.”

“Trust, but verify.”