🚀 go-pugleaf

Arno Welzel schrieb:
> Matthias Leisi schrieb:
> 
>> Arno Welzel schrieb:
>>
>>>> Kompiliert hei�t nicht, dass daraus nativer Maschinencode wird.
>>> Gut, dass der SpamAssassin auf meinem Server davon nichts wei� und
>>> trotzdem als Daemon l�uft ;-)
>>
>> Was hat Maschinencode mit "als Daemon laufen" zu tun? spamd, der
> 
> Dass es sich dabei um ein compiliertes Programm im Speicher handelt.

Das hat aber nichts mit "nativem Maschinencode" zu tun. Perl wandelt den
Sourcecode in eine interne Repr�sentation desselben um. Diese
Repr�sentation ist aber explizit _nicht_ nativer Maschinencode (mit
Ausnahme von allf�lligen Modulen, welche als native Bibliothek
eingebunden werden, unabh�ngig von der Ausf�hrungart).

Der spamd-Prozess ist ganz normaler, regul�rer Perl-Code. Der
Geschwindigkeitsvorteil gegen�ber dem spamassassin-Binary kommt daher,
dass 1) der Perlcode nicht bei jedem Aufruf gelesen und interpretiert
werden muss und 2) dass die Regeln und Konfigs nicht jedes mal neu
gelesen und interpretiert werden m�ssen.

Punkt 2 ist um eine Gr�ssenordnung "teurer" als Punkt 1.

> Korrekt. Und das tut man, um den Overhead der st�ndigen Neucompilierung
> zu vermeiden. spamd ist n�mlich wesentlich fixer, als der Aufruf des
> Perl-Scripts bei jeder einzelnen Mail. Das ist nat�rlich auch mit
> Sicherheitsrisiken verbunden, derer man sich bewusst sein sollte, worauf
> die Doku auch hinweist.

Allf�llige Sicherheitsrisiken haben so ziemlich gar nichts mit den
Kompiliereigenschaften oder Laufzeitverhalten zu tun, sondern zB mit der
Tatsache, dass spamd auf einem Socket lauscht.

-- Matthias