Fügt "use ..." oben einen Overhead zu einem Perl-Skript hinzu?

Wenn sie BEGIN Blöcke oder import Routinen haben, dann fügt das ja immer Overhead hinzu. Eventuell wird auch jeder Mainline-Code ausgeführt und alle INIT , CHECK und END Blöcke werden ebenfalls ausgeführt.

Der einzige Weg, um keinen Overhead hinzuzufügen, ist, wenn das Modul use nicht mehr als wie require erwartet. (Natürlich macht require auch alles außer der import -Routine, aber deshalb habe ich die Ansicht aus dem use -d-Modul erwähnt. Es erwartet "nichts weiter als ein einfaches" require .)

Wenn Sie diese Zeile beibehalten möchten, kommentieren Sie sie aus irgendeinem Grund. In der Entwicklung ist es in Ordnung, Module zu verwenden, die Sie nicht verwenden. In QA oder Produktion, das ist ein Fehler, IMO.

Perl muss den Code in Dumper.pm analysieren, damit Ihr Programm langsamer startet. Dies ist normalerweise ein sehr trivialer Erfolg. Außerdem wird jeder Code ausgeführt, der nicht in Funktionen oder in der Importfunktion enthalten ist. Dies kann sich geringfügig auf die Startzeit auswirken. Sie verbrauchen auch mehr Speicher (die AST für den Code und alle Datenstrukturen, die der Code erstellt). Es ist nicht das Beste, was Sie tun können, aber es ist bei weitem nicht das Schlimmste. Wenn Ihre Programme nicht oft (mehrmals pro Minute) verwendet werden, sollten Sie keine wirkliche Verbesserung der Geschwindigkeit feststellen, indem Sie die Zeile entfernen.

Jede Verwendung verbraucht Zeit, bevor das Skript gestartet wird, und erhöht wahrscheinlich den Speicherbedarf des Skripts. Um den Overhead zu testen, können Sie das folgende Skript ausführen:

Der Speicherbedarf im Task-Manager betrug 2548 KB.

Fügen Sie jetzt

und erneut testen:

Diesmal war der Speicherbedarf 3408K. Sie verschwenden also etwas Zeit und etwas Speicher, wenn das verwendete Modul nicht wirklich genutzt wird.

Die Startup-Zeit spielt in Skripten eine Rolle, die wiederholt aufgerufen werden (wie CGI), und der Speicherbedarf spielt unter anderem bei lang laufenden Skripten und Skripten eine Rolle.

Dies kann wichtig sein, wenn Ihr Skript wiederholt ausgeführt wird und es eine Latenz- oder Laufzeitbeschränkung gibt.

Wenn beispielsweise ein Prozess bei jeder Wiedergabe einer Webseite gegabelt wird, möchten Sie wahrscheinlich die Menge an Code minimieren, die Sie beim Laden analysieren, indem Sie nicht verwendete Module entfernen.

Oder wenn Sie Perl auf der rechten Seite von xargs ausführen.

Es gibt andere Möglichkeiten, diesen Overhead in der Situation des Webservers zu entfernen.

Wenn Sie fragen, stört Sie das nicht. Ja, es fügt etwas Overhead hinzu. Code:

entspricht fast genau:

Dies bedeutet, dass das Modul Data :: Dumper in der Kompilierungszeit geparst und body ausgeführt wird, sofern es noch nicht geschehen ist. Es bedeutet, dass, wenn Sie viele Module haben und Data :: Dumper in jedem verwenden, dieser Overhead nur einmal auftritt. Überprüfen Sie für bereits getan, ist sehr schnell, wirklich sehr schnell. Die zweite Zeile importiert den Aufruf und installiert die Importe in den aktuellen Paketnamen (vom Aufrufer erhalten). In allen Modulen braucht es einige Zeit. Wenn Sie es vermeiden möchten, verwenden Sie:

Dann können Sie nicht Dumper() aufrufen, aber Sie müssen Data::Dumper::Dumper() verwenden. Ich bevorzuge Data::Dumper->Dump([vars], [names]) , die mir eine Ausgabe bringen, die ich mehr mag.

Das ist nicht ganz das, was Sie gefragt haben, aber ich finde, Data :: Dumper ist eine Krücke und eine Gewohnheit, die es wert ist, gebrochen zu werden. Da Perl der Philosophie folgt, dass anderer Code eher freundlich als bösartig ist, ist es sehr verlockend für den Programmierer, Data :: Dump ein undurchsichtiges Objekt zu entdecken, um herauszufinden, wie seine Interna gespeichert sind, und dann direkt auf diese Interna zuzugreifen bereitgestellte Schnittstellen. Data :: Dumper ist einer der Gründe, warum Inside-Out-Objekte erstellt wurden - um es scharfen, aber ungeduldigen Programmierern zu erschweren / unmöglich, durch Interna herumzuschnüffeln.