Ich habe jetzt keine Statistik zur Hand, aber ich glaube, die meisten Module, die "native" Code verwenden, benutzen die XS Schnittstelle.

Der Grund ein XS Modul zu schreiben ist in aller Regel entweder eine existierende C-Bibliothek, die gut ist, und die man nicht in Perl neuschreiben will, oder aber die mögliche höhere Geschwindigkeit von "native" Code. Man muss hier aber durchaus abwägen, ob eine Lösung mit "native" Code wirklich schneller ist. In der Regel ist das nur dann der Fall, wenn das Programm, das man im Endeffekt schreibt auch wirklich viel Zeit bei rechenintensiven Aufgaben im "native" Code verbringt, also zum Beispiel riesige Matrixmultiplikationen hier ausführt. Gibt es hingegen sehr viel "Hin und Her" zwischen Perlcode und "native" Code, so kann die Notwendigkeit der Datenkonvertierung an der Schnittstelle Perl <-> "native" Code das Programm sogar viel langsamer als eine pure Perllösung machen.

Die Funktionsweise von XS Modulen ist, grob skizziert, so: Es gibt ein pures Perlmodul, das als Platzhalter für den eigentlichen "native" Code dient, aber auch zusätzlichen unterstützenden Perlcode enthalten kann. Daneben gibt es eine XS-Datei, bei der es sich im wesentlichen um C-Code mit zusätzlichen Präprozessorfeatures handelt. Diese XS-Dateien werden von einem mit Perl mitgelieferten Präprozessor zunächst in pures C übersetzt und anschließend durch den systemeigenen C-Compiler geschickt. Die resultierenden Objekte werden in eine dynamische Bibliothek gelinkt. Wir das Modul dann von Perl geladen, so wird nicht nur der Platzhalter, sondern auch die dynamische Bibliothek in den Speicher geladen und eine Initialisierungsroutine fügt die definierten XS-Subroutinen zu Perl hinzu.

Alternativ zum erstellen einer dynamischen Bibliothek können die XS-Subroutinen auch statisch direkt in den Perlinterpreter gelinkt werden.