[PDF] Сортировка страниц по их размерам

[zollinger]

Посмотреть вложение 179974

Попробуй запускать cpdf не отдельными вызовами/запусками, а через AND, так оно еще быстрее должно стать

 

[visitor2021]

В ресурсах старая версия, брать нужно было вот отсюда же [PDF] - Сортировка страниц по их размерам
Про "не дождался" это странно. 5,27 сек - это внушает

С новой версией и 100к страниц, после ~ 15 минут не дождался, убил. Видимо, не дошло до стадии 4-х рабочих, да и одно ядро даже не грузит. Не исключено, идиосинкразия ваших библиотек к PDF от GS. Хотите, разбирайтесь

100к страниц с колонцифрами (~ минута):

%PS

% gswin64c -q -sDEVICE=pdfwrite -o pages.pdf this_file.ps

/P [
[298 420]   [420 595]   [595 842]
[842 1191]  [1191 1684] [1684 2384]
[2384 3370]
] def
/L P length def

/Times findfont
72 scalefont setfont

1 1 100000 {
    << /PageSize P rand L mod get >> setpagedevice
    72 72 moveto
    6 string cvs show
    showpage
} for

 

[visitor2021]

идиосинкразия ваших библиотек к PDF от GS.

а, ну так и есть, перестроил плоский массив (который GS делает) из 100к страниц в "дерево" с "не более 10 ветвей/листьев на ветку" (тогда и Adobe Reader поживее листает этот файл), и все исправилось:

Zollinger
pdfsizes.exe
12.3801609

все ок, отбой, наличие колонцифр ни при чем, ушел (хотя, кстати (или нет) на выходе в файлах опять ~ по 14к в каждом плоские массивы вместо деревьев. Не откроет свой же собственный файл повторно, если будет в каком-нибудь e.g. 99k)

 

[zollinger]

Вообще, конечно, для чистоты эксперимента стоило бы использовать тот же тестовый файл 100k, что и мы использовали.
[PDF] - Сортировка страниц по их размерам
Ну и нам вот этот "плоский" выдать тоже неплохо бы, не ps-исходник, а именно рабочий файл

 

[visitor2021]

Не-не, интереснее сюжет, когда родитель не может справиться со своим же трудным дитём, что приводит к их неминуемой погибели, в назидание всем. Деревья, конечно, анахронизм эпохи, когда объем памяти измерялся в мегабайтах. Видимо что-то O(2**N) у вас.

cpdf -create-pdf -create-pdf-pages 100000 -o junk.pdf
pdfsizes.exe sr junk.pdf
pdfsizes.exe sr "junk pages 0001-100000 A4 (100000 pg.).pdf"
^C

 

[zollinger]

гляну вечером, интересно

 

[Drawer]

Не по теме:
А кстати да, я сталкивался с таким в cpdf Когда созданные им же файлы приходилось прогонять акробатовским фиксапом, чтобы cpdf их еще раз обработал На задаче из этой темки, когда пытался сделать раскладку по ТЗ ТС используя cpdf.

 

[zollinger]

Не-не, интереснее сюжет, когда родитель не может справиться со своим же трудным дитём, что приводит к их неминуемой погибели, в назидание всем. Деревья, конечно, анахронизм эпохи, когда объем памяти измерялся в мегабайтах. Видимо что-то O(2**N) у вас.

cpdf -create-pdf -create-pdf-pages 100000 -o junk.pdf
pdfsizes.exe sr junk.pdf
pdfsizes.exe sr "junk pages 0001-100000 A4 (100000 pg.).pdf"
^C

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

 

[~RA~]

Я уже потерял нить обсуждения, но тоже до кучи запущу.

Но в этой версии у меня ещё api.Encrypt вызывается.

 

[zollinger]

Да, у меня там использована одна не лучшая идея. Думаю, я её поправлю. Специфический синтетический тест, отсюда нюансы