It is really, really crucial that you objectively determine ... do not guess ... exactly where your present, one-language solution (or, solutions) are spending their time.   Most applications follow the 80/20 rule:   80% of the time is spent in 20% of the code.   Also, in most cases an application spends most of its clock-time in the theatre ... “waiting for god-I/O-t.”   You gain no advantage at all if you optimize what the app does not spend most of its time doing.   But if the application does do “something very-computational millions of times,” it creates a hot-spot that might benefit from being recoded in an XS subroutine.   Many of the CPAN packages that you use every day, do have an XS optimization or three ... as well, as, usually, a “pure-Perl” alternative.

Most applications wind up doing exactly the same handful of things ... especially, data-structure manipulation.   This is where Perl and other languages shine.   The “overhead” of having a bytecode-interpreter in the center of everything is small enough that it can be ignored, as can the one-time cost of translating source-code into bytecode, and the logic within the interpreter that does the “heavy lifting” (hashes, lists, memory manager, and such ...) is both thoroughly optimized and thoroughly debugged.   Since it takes a lot less time to use [Perl] to accomplish a result that runs pragmatically “just as fast as” something that you labored days on hand-crafting, Perl wins a lot of hands.   The time that you save, is your own.