When talking about SSI, it helps to distinguish between using #include, which doesn't spawn additional processes, and #exec, which does. The performance difference is significant. (This sounds kind of "well, duh!", but some web servers don't support #exec.)

If all you're doing is including new fragments at page assembly time, mod_perl and SSI should be equivalent. A lot of systems rely on "dynamically" assemblying from static content that is periodically regenerated. Things get tricker when the content has be assembled on the spot.

If you would be using SSI #exec to prepare dynamic content at page assembly time, then mod_perl is going to be faster (by virtue of not having to start a new processes).

If you're not able to use mod_perl, then you need to start counting process starts to predict whether SSI or CGI will be faster. In the case of including static content, SSI is going to win, since #include doesn't involve starting any new processes. Beyond that, and all other factors being equal^*, then it comes down to counting process starts. A CGI that can assemble content without having to fork subprocesses is liable to beat out an SSI that assembles content using 2 or more #exec's.

^* Other factors include maintainability of separate scripts, separation of static and dynamic content, ability of a designer to edit HTML (vs. forcing them to become programmers), etc.