LINUX.ORG.RU

find работает быстрее imagemagick на поиске списка файлов?

 , ,


0

1

Выполняю задачу: конвертировать pdf в картинки и повернуть их на 90°.

Виснет, потом отваливается с вердиктом «убит», да, так и пишет.

time convert -density 300 -quality 80 -depth 8 file.pdf file-%02d.jpg

Срабатывает:

time pdfimages -png file.pdf file

Хотя раньше оба варианта работали. Но у меня подыхает ПК, дикие зависания, поэтому кто быстрее сразу выяснилось.

Далее поворачиваю их на 90°:

mogrify -rotate 90 'csr10-%03d.png[002-024]'

Пишет, что Убит или Ошибка шины (стек памяти сброшен на диск)

А через find срабатывает:

find csr*.png -exec mogrify -rotate 90 {} \;

Что мой ПК пора на помойку это я уже давно знаю. Но скажите мне пожалуйста, почему IM такой ёмкий тормоз, а pdfimages, find - вжик? Неоптимальный код, Не на питоне же его писали?

Ответ на: комментарий от vbr

Думаете? Раньше на этом же ПК в этой же конфигурации ему свопа хватало и на более ёмкие операции. Тут в быстродействие упирается. Почему-то задача ждёт своей очереди к ЦП, и просто не выполняется.

hikikomori ★★★
() автор топика
Ответ на: комментарий от hikikomori

Тут в быстродействие упирается.

По твоему же описанию следует что упирается оно в нехватку RAM:

дикие зависания

потом отваливается с вердиктом «убит», да, так и пишет.

Скорее всего это приходит OOM Killer и убивает сильно жрущий RAM процесс.

Но тогда другой вопрос, почему конструкции в ImageMagick для пакетной обработки изображений жрут так много RAM.

Bus Error кстати намекает на ошибки памяти. Прогонял memtest?

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)

Потому что ты первой командой вызываешь mogrify на все файлы сразу, а find в такой конструкции будет вызывать mogrify на каждый файл по отдельности.

В результате первая команда не влезает в память, а вторая влезает.

Aceler ★★★★★
()
Ответ на: комментарий от EXL

давно не прогонял, но у меня дело в другом. свежеребутнутая система работает быстрее уже час работающей. Хочешь что-то сделать - ребуться… Я уже устал переставлять линукс как венду95.

hikikomori ★★★
() автор топика
Ответ на: комментарий от EXL

Но тогда другой вопрос, почему конструкции в ImageMagick для пакетной обработки изображений жрут так много RAM.

Он, если я правильно понимаю, ещё и конвертирует изображения в 16bpc, что тоже сказывается на масштабах жора.

token_polyak ★★★★
()
Последнее исправление: token_polyak (всего исправлений: 2)
Ответ на: комментарий от no-such-file

Не знаю, считается ли GNU нынче хипстерскими или нет, но что-то типа. Смысл в том, что (как очевидно из названия) процессы запускаются не один за другим (как в случае с xargs), а параллельно, что во многих случаях сильно ускоряет всё это дело целиком.

Подробнее. А так оно ещё и на несколько машин по ssh позволяет параллелить, что иногда (при очень CPU-heavy операциях, например перекодирование видео) бывает тоже весьма полезно.

CrX ★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Команды parallel не найдено.

yay -Ss parallel выдал туеву хучу вариантов. Примеры бы использования ещё, и какие статьи на русском шо за зверь, по ней есть? Просто очень мало времени на чтиво глубоко погружаться(

hikikomori ★★★
() автор топика
Последнее исправление: hikikomori (всего исправлений: 1)
Ответ на: комментарий от hikikomori

yay -S parallel ;)

Примеры есть в документации, а так… Ну оно почти как xargs с точки зрения интерфейса пользователя. Только параллелит. Насчёт статей, тем более на русском, не знаю, мне чтение man’а было вполне достаточно, чтобы всё понять.

Вот простой пример из жизни, которым я часто пользуюсь, например:

mkdir -p reencoded && parallel 'flac -8 -e {} -o reencoded/{}' ::: *.flac — перекодировать все флаки в текущей директории с наивысшим сжатием.

CrX ★★★
()
Последнее исправление: CrX (всего исправлений: 1)