Будет ли Perl узким местом в такой обработке изображений? - PullRequest
4 голосов
/ 14 февраля 2010

Обработка, которую я имею в виду, такова:

  • Есть тысячи файлов PNG
  • каждый из них должен быть загружен, а его пиксели доступны
  • каналы каждого пикселя будут каким-то образом обрабатываться, а затем записываться в двоичный файл

Я думал об использовании какого-либо модуля, такого как обертки ImageMagick, или какой-то другой обертки для бэкэнда обработки изображений на Си. Не замедлит ли меня Perl, если я выберу его для реализации этой задачи? У меня уже есть инструмент, написанный на Java (он использует BufferedImage JDK), и он достаточно быстрый. Буду ли я сумасшедшим ожидать такой же скорости от Perl?

Ответы [ 4 ]

9 голосов
/ 14 февраля 2010

Если вы используете ImageMagick или какой-либо другой инструмент обработки на основе C, Perl наверняка не станет узким местом. Узкие места, которые я мог видеть (особенно если обрабатывал тысячи файлов), были бы:

  • Скорость дискового ввода-вывода
  • Скорости доступа к памяти
  • Скорость работы алгоритма библиотеки

Perl сделает отличный клей для того, что вы хотите. Медленные части все еще будут медленными. Вы могли бы также сделать быстрые части легкими. :)

Также запомните два правила оптимизации:

  1. Не делай этого.
  2. (Только для экспертов:) Пока не делайте этого.

Когда вы соберете его, запустите на нем профилировщик. Если и когда это станет вашей целью, проверьте:

http://metacpan.org/pod/Devel::NYTProf

Devel :: NYTProf - колени пчелы, когда дело доходит до инструментов для профилирования. Он точно покажет, где ваши замедления, так что у вас не просто «теплое нечеткое» чувство, что вы правильно поняли… вы точно будете знать.

4 голосов
/ 14 февраля 2010

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

3 голосов
/ 14 февраля 2010

Ответ зависит от того, что ограничивает производительность в версии Java. Если вы ограничены файловым вводом / выводом (включая декомпрессию .png), то переход на Perl, вероятно, будет в порядке. В противном случае вы, скорее всего, заплатите крутое снижение производительности за обработку каждого пикселя в Perl, но если вы можете вызывать подпрограммы C для обработки целых изображений, вы, вероятно, будете такими же быстрыми (возможно, быстрее, в зависимости от относительной производительности библиотеки C и Java).

Итак, вкратце: если Perl должен касаться пикселей, он будет медленным. Если Perl касается изображений, а C - пикселей, это, вероятно, нормально.

1 голос
/ 15 февраля 2010

Да, я ожидаю, что производительность реализации perl будет невероятно плохой при обработке изображений на уровне пикселей.

Да, вы могли бы сделать это, но структуры данных Perl не поддаются подобным вещам. Если вы использовали библиотеку, где вам не нужно совершать 1x вызов на пиксель, все будет в порядке.

...