Один вариант, который все еще может быть довольно медленным по сравнению с perl
, но его стоит сравнить:
raku -ne '++$ andthen END .say' test.txt
Параметр командной строки l
является избыточным.
$
- это скаляр анонимного состояния.
andthen
проверяет, что определены его lhs, и, если да, устанавливает это значение как топи c ($_
), а затем оценивает его rhs.
END
аналогично perl
END
. Обратите внимание, что он возвращает Nil
в andthen
, но это не имеет значения, потому что мы используем оператор END
для его побочного эффекта.
Несколько факторов влияют на скорость этого кода , Некоторые вещи, о которых я могу подумать:
Затраты на запуск компилятора. Игнорируя любые используемые модули, компилятор raku
Rakudo имеет нагрузку на запуск около десятой части секунда на типичном оборудовании по сравнению с довольно незначительным для perl
.
Понятие "линия". В perl
, понятие по умолчанию Обработка строки читает серию байтов, некоторые из которых представляют конец строки. В raku
стандартным понятием обработки строки является чтение строки UTF-8, часть которой представляет конец строки. Таким образом, perl
несет только накладные расходы на чтение декодера ASCII (или Extended ASCII), тогда как raku
накладывает накладные расходы на чтение декодера UTF-8.
Оптимизация компилятора . perl
обычно оптимизируется до макс. Меня не удивит, если perl -lnE 'END {say $.}' test.txt
использует некоторые умные оптимизации. В отличие от этого, работа по оптимизации Rakudo все еще находится на начальном этапе, если говорить относительно.
Единственные вещи, которые я думаю, что каждый может сделать с первым и последним из трех пунктов, которые я упомянул выше нужно подождать N лет и / или внести свой вклад в улучшение компилятора.
Будет способ обойти UTF-8 по умолчанию в raku. Возможно, что-то вроде следующего уже выполнимо и значительно быстрее, чем стандартное значение raku, по крайней мере игнорируя издержки использования модуля с именем foo
:
raku -Mfoo -ne '++$ andthen END .say' test.txt
, где module foo
переключает кодировку по умолчанию для файла I / O в ASCII или что-либо из доступных кодировок .
Я не проверял, что это реально выполнимо в текущем Rakudo, но был бы удивлен, если бы не было.