Влияют ли комментарии на производительность Perl?

Perl компилирует сценарий и затем выполняет его. Комментарии незначительно замедляют фазу компиляции, но не влияют на фазу выполнения.

Производительность во время выполнения? Нет.

Производительность парсинга и лексирования? Да, конечно.

Поскольку Perl имеет тенденцию к синтаксическому анализу и лексированию на лету, комментарии будут влиять на производительность при "запуске".

Заметно ли они повлияют на это? Навряд ли.

Я ожидал, что один комментарий будет проанализирован только один раз, а не несколько раз в цикле, поэтому я сомневаюсь, что это действительный тест.

Я ожидал, что комментарии немного замедлят компиляцию, но я полагаю, что их будет слишком мало, чтобы их удалить.

Из комментария Пола Томблина:

Doesn't perl do some sort of on-the-fly compilation? Maybe the comments get discarded early? –

Да, Perl умеет.

Это промежуточный язык программирования, скомпилированный и интерпретируемый. Код компилируется на лету и затем запускается. комментарии обычно не имеют никакого значения. Наибольший эффект от этого, вероятно, будет заключаться в том, что когда он изначально анализирует файл построчно и предварительно компилирует его, вы можете увидеть разницу в наносекунду.

Замедляют ли комментарии Perl сценарий? Ну разобрать, да. Выполнить его после разбора? Нет. Как часто анализируется сценарий? Только один раз, поэтому, если у вас есть комментарий в цикле for, комментарий отбрасывается синтаксическим анализом один раз, прежде чем скрипт даже запустится, после того, как он начал работу, комментарий уже исчез (и скрипт не сохраняется как скрипт внутри Perl), поэтому независимо от того, сколько раз цикл for повторяется, комментарий не будет иметь значения. Как быстро парсер может пропускать комментарии? Комментарии Perl сделаны очень быстро, поэтому я сомневаюсь, что вы заметите. Вы заметите более длительное время запуска, если у вас будет 5 строк кода и между каждой строкой 1 миллион строк комментариев ... но насколько вероятно это и какой смысл будет в таком большом комментарии?

Perl не является языком сценариев в том же смысле, что и сценарии оболочки. Интерпретатор не читает файл построчно. Выполнение программы Perl выполняется в два основных этапа: компиляция и выполнение [1]. На этапе компиляции исходный код анализируется и преобразуется в байт-код. На этапе выполнения байт-код выполняется на виртуальной машине.

Комментарии замедлят этап синтаксического анализа, но разница незначительна по сравнению со временем, необходимым для анализа самого скрипта (которое и так очень мало для большинства программ). Примерно единственный раз, когда вы действительно озабочены анализом времени, - это среда веб-сервера, где программа может вызываться много раз в секунду. mod_perl существует для решения этой проблемы.

Вы используете Benchmark. Это хорошо! Вам следует искать способы улучшения алгоритма, а не микрооптимизации. Devel :: DProf может быть полезен для поиска горячих точек. Вы абсолютно не следует удаляете комментарии в ошибочной попытке сделать вашу программу быстрее. Вы просто сделаете его недостижимым.

[1] Это обычно называется компиляцией «точно в срок». На самом деле Perl имеет еще несколько этапов, таких как INIT и END, которые здесь не имеют значения.

Суть в том, чтобы оптимизировать узкие места. Чтение файла состоит из:

• открытие файла,
• чтение в его содержании,
• закрытие файла,
• анализ содержимого.

Из этих шагов чтение - самая быстрая часть (я не уверен насчет закрытия, это системный вызов, но вам не нужно ждать его завершения). Даже если это 10% всего (что, я думаю, не так), то уменьшение его вдвое дает только 5% улучшение производительности за счет отсутствия комментариев (что очень плохо). Для парсера отбрасывание строки, начинающейся с символа #, не является ощутимым замедлением. А после этого комментарии ушли, так что замедления быть не может.

Теперь представьте, что вы могли бы улучшить часть «чтение в сценарии» на 5%, удалив все комментарии (что является действительно оптимистичной оценкой, см. Выше). Насколько велика доля «чтения в сценарии» в общей затрате времени на сценарий? Конечно, это зависит от того, насколько сильно он работает, но поскольку сценарии perl обычно читают по крайней мере еще один файл, это не более 50%, но поскольку сценарии perl обычно делают что-то большее, честная оценка снизит это до чего-то в диапазоне от 1%. Итак, ожидаемое повышение эффективности за счет удаления всех комментариев составляет всамый (очень оптимистично) 2,5%, но действительно ближе к 0,05%. Кроме того, те, у которых он действительно дает более 1%, уже работают быстро, поскольку они почти ничего не делают, поэтому вы снова оптимизируете не в том месте.

В заключение оптимизируйте узкие места.

Perl - это язык, компилируемый точно в срок, поэтому комментарии и POD не влияют на производительность во время выполнения.

Комментарии и POD незначительно влияют на время компиляции, но Perl так легко и быстро анализирует их, что практически невозможно измерить снижение производительности. Вы можете убедиться в этом сами, просто используя флаг -c для компиляции.

На моем Macbook программа Perl с 2 операторами и 1000 строками из 70-символьных комментариев занимает то же время, чтобы скомпилировать программу с 1000 строками пустых комментариев и программу с двумя операторами печати. Обязательно запускайте каждый тест дважды, чтобы ваша ОС могла кэшировать файл, иначе то, что вы тестируете, - это время для чтения файла с диска.

Если время запуска для вас проблема, то не из-за комментариев или POD.

Модуль Benchmark в этом случае бесполезен. Это всего лишь измерение времени, в течение которого код запускается снова и снова. Поскольку ваш код на самом деле ничего не делает, большая часть его оптимизируется. Вот почему вы видите, как он запускается 22 миллиона раз в секунду.

У меня почти вся глава об этом в Освоение Perl. Погрешность измерения в методике Benchmark составляет около 7%. Ваши контрольные цифры находятся в пределах этого, так что практически нет никакой разницы.