Как ускорить обработку данных фиксированной ширины Perl?

Question

У нас есть зрелый код, который загружает данные из файлов в базу данных. Существует несколько форматов файлов; все поля фиксированной ширины.

Часть кода использует функцию Perl unpack() для чтения полей из входных данных в переменные пакета. Бизнес-логика тогда может обращаться к этим полям «с точки зрения человека».

Код чтения файла создается из описания формата один раз, перед чтением файла.

В эскизе формы, сгенерированный код выглядит следующим образом:

while (<>) { 

    # Start of generated code. 

    # Here we unpack 2 fields, real code does around 200. 
    ($FIELDS::transaction_date, $FIELDS::customer_id) = unpack q{A8 A20}; 

    # Some fields have leading space removed 
    # Generated code has one line like this per affected field. 
    $FIELDS::customer_id =~ s/^\s+//; 

    # End of generated code. 

    # Then we apply business logic to the data ... 
    if ($FIELDS::transaction_date eq $today) { 
     push @fields, q{something or other}; 
    } 

    # Write to standard format for bulk load to the database. 
    print $fh join('|', @fields) . q{\n} or die; 
} 

Профилирование кода показывает, что около 35% времени тратится на распаковке и ведущее пространство полоса. Оставшееся время тратится на проверку и преобразование данных и запись в выходной файл.

Похоже, что нет единой части бизнес-логики, которая занимает более 1-2% от времени выполнения.

Вопрос: можем ли мы немного ускорить процесс распаковки и снятия пространства? Предпочтительно без необходимости рефакторировать весь код, который относится к переменным пакета FIELDS.

EDIT:

В случае это разница

$ perl -v 
This is perl, v5.8.0 built for PA-RISC1.1 

Answer 1

Да. Извлечение с использованием substr, вероятно, будет самым быстрым способом сделать это. То есть:

$FIELDS::transaction_date = substr $_, 0, 8; 
$FIELDS::customer_id  = substr $_, 8, 20; 

, скорее всего, будет быстрее. Теперь, если бы я почеркнул этот код, я бы не отказался от unpack, но если вы генерируете код, вы можете также дать ему шанс и измерить.

Смотрите также ответы на Is Perl’s unpack() ever faster than substr()?

Как для зачистки ведущие пробелы, s/^\s+//, вероятно, будет самым быстрым способом.

Обновление: Трудно сказать что-то определенное, не имея возможности запускать тесты. Однако, как насчет:

my $x = substr $_, 0, 8; 

для полей, которые не нуждаются в какой-либо обрезке и

my ($y) = substr($_, 8, 20) =~ /\A\s+(.+?)\s+\z/; 

, которые нужны зачистка?

Answer 2

Я действительно занимался этой проблемой снова и снова. Unpack is better than substr.

Что касается пробелов, вы в значительной степени завинчены. Этот румян регулярного выражения - это «официальный» способ сделать это. Вы могли бы получить некоторую эффективность, уточнив свои распаковывающие утверждения (если данные не превышают 4 цифры, зачем распаковывать полные 12 цифр поля?), Но в противном случае синтаксический анализ будет всего лишь p.i.t.a.

Удачи вам в ваших плоских данных. Заворачивание старого мусора, как я его ненавижу.

Answer 3

Вы уверены, что используете этот процессор? Вычисление достаточно просто, чтобы заподозрить, что весь процесс, вероятно, будет связан с I/O. В этом случае оптимизация для быстрой распаковки не принесет вам много времени.

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

Answer 4

Это может быть что-то для XS - так, чтобы вы использовали функцию C для изменения данных. Я мог представить, что это намного быстрее, чем что-либо еще, поскольку вы можете вручную управлять, когда данные действительно скопированы.
Процесс сборки будет усложняться, поскольку у вас есть зависимость от компилятора C и потребуются дополнительные шаги интеграции.

Answer 5

Просто сделайте это параллельно. Это тривиально, и на любой даже отдаленно современной машине это будет быстрее.

Answer 6

Базовая версия нашего кода, основанного на основах, предположила, что она может быть примерно на 50% быстрее, чем наша существующая распаковка. Сравнивая коды на месте в реальном приложении, версия substr дала нам сокращение времени выполнения на 16%. Это близко к тому, что мы надеялись на основе эталона и профилирования, о которых идет речь в вопросе.

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

идиома мы имеем сейчас:

$FIELDS::transaction_date = substr($_, 0, 8) || ''; 
$FIELDS::transaction_date =~ s/\s+\z//; 
$FIELDS::customer_id = substr($_, 8, 20) || ''; 
$FIELDS::customer_id =~ s/\s+\z//; 

с последующим селективным удалением ведущего пространства, как и раньше.

Спасибо за все ответы. Я соглашусь с Синан, потому что это сработало для нас, несмотря на то, что оно «просто неправильно».