Biztos, hogy PHP-val nagyobb az erőforrásigény, mint htaccessel?Egészen biztos. De nyugodtan meg is mérheted. Rewrite esetén egyszer felparseolja a szöveges fájlt, aztán felparseolt formában tárolja és helyben használja a memóriából a webszerver, semmilyen más erőforrásigény sem másik processzel való kommunikáció nincs a dologban. Ha rendesen van megírva, akkor a regexpeket is eleve felparseolt, tokenizált formában tárolja, és még Linux syscall hívásokra sincs szükség, helyben, a webszerver felhasználói memóriájában lerendez mindent. Ezzel szemben PHP esetén: 1. össze kell állítani a php környezet a http fejlécek konvertálásával, query és post értelmezéssel stb. 2. php interpreter indulásának is van overheadje, potenciálisan másik processz, át kell neki adni a környezetet 3. a php-ból ki kell építeni a kapcsolatot az adatbázisszerver felé 4. az sql query-t át kell adni az adatbázisszervernek a kapcsolaton keresztül 5. a query-t a szervernek fel kell parseolni és tokenizálni kell (ezt mindig meg kell tenni, mert a query szövegesen érkezik a kapcsolaton keresztül) 6. a query-t le kell futtatni (külön lemezművelet, nem biztos, hogy az eredmény cache-elve van) 7. az eredményt át kell adni a php-nak a kapcsolaton keresztül 8. a php-nak a nyers kommunikációt át kell alakítania php változókká (jellemzően a db plugin és esetleg a PDO dolga) 9. az eredményt fel kell dolgozni php-ból (a tényleges Symfony routing)
Más webszervereken meg nincs is.Minden webszerver tud rewrite-ot, direkt belinkeltem több dokumentációját is, hogy hogyan. A fenti mintám például nginx-es.
A PHP meg már elég jól gyorsítja a kódot.Nem a php értelmezés a gyenge láncszem, hanem a rengeteg IPC, socket írás-olvasás (ezekhez rengeteg Linux syscallra és felhasználói-kernel memória közti másolásra is szükség van), no meg a különböző adatreprezentációk közti másolgatás és folyamatos konvertálgatás. A php interpreter elenyésző szelete csak a teljes overheadnek egy adatbáziskapcsolatot használó szkript esetén.