На какъвто и език да го напишеш, CGI скрипта е далеч по-бавен вариант от mod_perl/mod_php или квото и да е там, което се обработва в рамките на apache worker-а.
При fastcgi нещата стоят малко по-различно, защото вече има форкнат cgi процес. Дали обаче ще намажеш особено много от гледна точка на performance, не е много сигурно.
Но и това не е причината, поради която такава идея не е много добра. Просто C/C++ не става за такива неща. Цял нов клас уязвимости и бъгове ще се въведат само заради избора на езика. При PHP/Perl/Python/J2EE, въобще не ти трябва да мислиш за това какво се случва с паметта. На C - трябва. Елементарни примери мога да дам - ще сбъркаш някъде в някоя функция да декларираш примерно char bla[200], ще направиш strcpy(bla,getenv("HTTP_USER_AGENT")); за да вземеш user agent-a на клиента, в момента в който се окаже че той е по-дълъг от 200 байта, препълваш буфера и вероятно приложението ще крашне. Това може да има и security последици. Друг пример - динамично заделяш памет според GET параметър зададен от потребителя. Зъл потребител просто заявява скрипта с голяма стойност на параметъра и твоят скрипт изяжда всичката РАМ на машината, която успее. Или пък някъде викваш malloc(), но забравяш да освободиш паметта, така паметта лека полека leak-ва...докато останеш без свободна памет. И такива работи. Езици като PHP ти спестяват ужасно много неща, с които ще си биеш главата на C, а и покрай това те лишават от възможността да въведеш определени видове бъгове в приложението.
На асемблер да пишеш уеб приложения....ехех, много смело
Ще ми се да видя някъде нещо такова