Halihallo Andres
Schneller kann use afaik nicht sein, da es einerseits das gleiche mahcte wie require und andererseits noch etwas mehr(siehe perldoc -f use).
Ich meine schon das es schneller ist, was sich jetzt gerade mal wieder bestätigt hat. Der Unterschied ist zwar bei meinem kleinen Testscript+Testmodul nicht groß, aber es gibt ihn.
Ich denke das liegt daran, dass der Syntaxprüfer und der Compiler (ja, ich weiß dass manche meinen, dass das so nicht genannt werden darf, aber selbst Larry Wall nennt es so) nicht neu gestartet werden müssen, sondern das ganze in einem Aufwasch durchschauen/kompilieren können.
Och, naja, ein Compiler ist Perl schon, nur, dass dieser nicht Maschinencode er-
zeugt, sondern Perl opcodes (sozusagen Maschinencode für die PerlVM). Klar, die
Hauptargumente dagegen sind a) der opcode wird ebenfalls noch "interpretiert" und
b) die Generierung des opcodes geschieht bei jedem Programmstart.
Wie du sagst, darüber kann man Streitgespräche führen, ich denke, dass beide recht und
unrecht haben... Ich sage: auch Maschinencode wird interpretiert, von der CPU nämlich,
warum man einen Unterschied zwischen Softwareinterpretation und Hardwareinterpretation
macht, verstehe ich nicht :-)
Zurück zum Thema: Ich weiss nicht, inwiefern Optimierungen vor/nach BEGIN durchgeführt
werden, oder welchen Einfluss sie auf das Alloziieren von Speicher hat. Ich hoffe, dass
ich das auch im genannten Thread gesagt habe. Ich könnte es mir vorstellen.
Fakt ist:
a) BEGIN/END sind keine normalen Prozeduren und können im Programm-Scope nicht als solche
angesprochen werden (könnten also "speziell" gehandhabt werden).
b) Speicherallozierung ist Zeitaufwändig und wird von Perl wenn möchlich optimiert
(eg. nicht mehr gebrauchte Variablen-Speicher (AV,SV,IV,HV,..) werden wiederverwendet)
was ich glaube ist:
a) Opcode-Optimizer startet vorher und somit wäre da der Zeitpunkt, wo Speicher
für die PerlVM alloziiert wird (später wird Speicher durch perlinterne Makros
verwaltet, falls Perl so kompiliert wurde, ggf. muss neuer Speicher vom OS
geholt werden).
b) Wenn also bereits Module beim Startup eingelesen werden, könnten Variablen im
Modul-Scope eigentlich beim Opcode-Optimizer erkannt werden und den Speicheraufwand
beeinflussen (den virtuellen Speicher zu der PerlVM zu begin festlegen, sodass der
Speicher nicht mehr zur Laufzeit vom OS angefordert werden muss und alles in einem
Block alloziiert wird).
Inwieweit, oder gar überhaupt, Optimierungen für BEGIN-Blöcke ausgeführt werden, weiss
ich leider nicht, wie gesagt, ich könnte es mir vorstellen.
Hast du wirklich Benchmarks ausgeführt und konntest du feststellen, dass use schneller
ist als require? - Denn Klaus'es Argumentation, dass use genau das macht, wie require
und noch ein bischen mehr, ist wahr. Zudem misst man beim Benchmark in dieser
mikroskopischen Welt wohl eher die Zeit des Betriebssystems die eventuell gecachte
Moduldatei auszulesen, als das Alloziieren von Speicher durch Perl, denn letzteres
geht im Vergleich doch rasant schnell... Ein Benchmarking auf dieser low-level-Ebene ist
mit leider grosser Vorsicht zu geniessen.
Viele Grüsse
Philipp
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.