Действительно “использует …”, наверху добавляют наверху к сценарию Perl?
Может быть, ваша активность будет убита, а затем воссоздана (например, при изменении ориентации экрана), так что ваш массив инициализируется нулевыми элементами, и все же какая-то другая часть вашей программы не знает об этом и ожидает, что этот массив будет иметь некоторые элементы ,
6 ответов
If they have BEGIN blocks or import routines, then yes, it always adds overhead. Also any mainline code will be executed eventually and any INIT, CHECK, and END blocks will also execute.
The only way it won't add overhead is if the module expects use to be nothing more than like require. (Of course, require also runs everything except the import routine, but that's why I mentioned the view from the use-d module. It "expects" to be nothing but a simple require.)
If you want to retain that line, for some reason, just comment it out. In development, it's okay to have modules that you don't use. In QA or production, that's a mistake, IMO.
Perl должен анализировать код в Dumper.pm , поэтому ваша программа будет медленнее запускаться. Обычно это очень незначительный удар по производительности. Кроме того, будет выполняться любой код, отсутствующий в функциях или в функции импорта. Это может незначительно повлиять на время запуска. Вы также будете потреблять больше памяти (AST для кода и любых структур данных, которые создает код). Это не лучшее, что вы можете сделать, но и далеко не самое худшее. За исключением случаев, когда ваши программы выполняются очень часто (несколько раз в минуту), вы не заметите никакого реального улучшения скорости при удалении строки.
Каждое использование требует времени до запуска вашего скрипта и, вероятно, увеличивает объем памяти, занимаемый скриптом. Чтобы проверить накладные расходы, вы можете запустить следующий сценарий:
C:\Temp> cat zzz.pl
#!/usr/bin/perl
sleep 10;
C:\Temp> timethis zzz.pl
TimeThis : Elapsed Time : 00:00:10.172
Объем памяти в диспетчере задач составил 2548 КБ.
Теперь добавьте
use Data::Dumper;
и проверьте еще раз:
TimeThis : Elapsed Time : 00:00:10.266
На этот раз объем памяти составил 3408 КБ. Таким образом, вы теряете время и немного памяти, если модуль, который вы используете, на самом деле не используется.
Время запуска имеет значение в сценариях, вызываемых повторно (например, CGI), а объем памяти имеет значение, среди прочего, в долго работающих сценариях и скрипты.
Если вы спросите, не не возражаю. Да, это добавляет некоторые накладные расходы. Код:
use Data::Dumper;
почти точный эквивалент:
BEGIN {
require Data::Dumper;
Data::Dumper->import();
}
Это означает, что во время компиляции модуль Data :: Dumper анализируется и выполняется тело, если это еще не сделано. Это означает, что если у вас много модулей и вы используете Data :: Dumper в каждом, то эти накладные расходы возникают только один раз. Проверка уже выполненных требований выполняется очень быстро, действительно очень быстро. Вторая строка выполняет вызов импорта и устанавливает импорт в текущее пространство имен пакета (полученное вызывающей стороной). Во всех модулях, где они используются, требуется некоторое время. Если вы хотите избежать этого, используйте:
use Data::Dumper ();
Тогда вы не можете вызвать Dumper () , но вы должны использовать Data :: Dumper :: Dumper () . Я предпочитаю использовать Data :: Dumper-> Dump ([vars], [names]) , который дает мне вывод, который мне нравится больше.
use Data::Dumper ();
Тогда вы не можете вызвать Dumper () , но вы должны использовать Data :: Dumper :: Dumper () . Я предпочитаю использовать Data :: Dumper-> Dump ([vars], [names]) , который дает мне вывод, который мне нравится больше.
use Data::Dumper ();
Тогда вы не можете вызвать Dumper () , но вы должны использовать Data :: Dumper :: Dumper () . Я предпочитаю использовать Data :: Dumper-> Dump ([vars], [names]) , который дает мне вывод, который мне нравится больше.
Dumper () , но вы должны использовать Data :: Dumper :: Dumper () . Я предпочитаю использовать Data :: Dumper-> Dump ([vars], [names]) , который дает мне вывод, который мне нравится больше. t вызовите Dumper () , но вы должны использовать Data :: Dumper :: Dumper () . Я предпочитаю использовать Data :: Dumper-> Dump ([vars], [names]) , который дает мне вывод, который мне нравится больше. Это может быть важно, если ваш скрипт выполняется многократно и есть задержка или ограничение времени выполнения.
Например, если это процесс, разветвляющийся каждый раз, когда отображается веб-страница , вы, вероятно, захотите свести к минимуму объем кода, который вы анализируете во время загрузки, удалив неиспользуемые модули.
Или если вы запускаете perl с правой стороны xargs.
Есть другие способы удалить эти накладные расходы в ситуация с веб-сервером.
Это не совсем то, о чем вы спрашивали, но я считаю, что Data :: Dumper - это костыль и привычка, от которой стоит отказаться. Поскольку perl следует философии предположения, что другой код является дружественным, а не вредоносным, для программиста очень заманчиво использовать Data :: Dump для непрозрачного объекта, чтобы узнать, как хранятся его внутренние компоненты, а затем получить доступ к этим внутренним компонентам напрямую, вместо того, чтобы использовать предоставленные интерфейсы. Data :: Dumper - одна из причин, по которой были созданы объекты Inside-Out - чтобы усложнить / сделать невозможным для увлеченных, но нетерпеливых программистов копаться во внутренностях.