We are generating images from PDF with the following command on xp: "c:\Program Files\gs\gs9.04\bin\gswin32c.exe" -q -sDEVICE=jpeg -dJPEGQ=90 -dUseTrimBox -dUseCropBox -r300x300 -o "201205_ro_01_174-%%02d.jpg" "AV1205_174_RO.pdf" The image creation normally takes around 20 seconds, but with the attached pdf it is more then 1 hour. The used memory is 500-600 Mb and the CPU is almost on 100% all the time. I tried adding the follwoing parameters to the command line, but didn't help. -c 60000000 setvmthreshold -f (sorry for the big pdf, i cannot edit it) Can you check this please? Thank you Szabolcs Hodossy
Created attachment 8339 [details] pdf causing extremely slow performance
The file renders almost 30K images. Profiling shows that most of the time is spent in memory management. Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 45.54 924.00 924.00 11868898 0.00 0.00 chunk_locate_ptr 25.14 1434.12 510.12 1722055 0.00 0.00 alloc_link_chunk 18.15 1802.50 368.38 7362931 0.00 0.00 large_freelist_alloc 2.43 1851.89 49.39 9388036 0.00 0.00 ptr_string_unmark 2.30 1898.57 46.68 5479 0.01 0.14 gs_gc_reclaim 0.67 1912.14 13.57 6998244 0.00 0.00 gs_memset 0.51 1922.52 10.38 31222068 0.00 0.00 refs_clear_marks 0.47 1932.15 9.63 57302919 0.00 0.00 igc_reloc_refs 0.42 1940.77 8.62 26063638 0.00 0.00 refs_set_reloc 0.40 1948.95 8.18 25831883 0.00 0.00 refs_compact 0.33 1955.74 6.80 89753049 0.00 0.00 igc_reloc_ref_ptr_nocheck 0.32 1962.25 6.51 54234 0.00 0.04 interp 0.18 1965.81 3.56 5158430 0.00 0.00 refs_clear_reloc 0.13 1968.40 2.59 13318858 0.00 0.00 names_ref 0.13 1970.98 2.58 33550950 0.00 0.00 gs_memcpy 0.12 1973.46 2.49 64381952 0.00 0.00 igc_reloc_ref_ptr 0.12 1975.81 2.35 11474 0.00 0.00 alloc_save__filter_changes 0.10 1977.93 2.12 9847982 0.00 0.00 dstack_find_name_by_index 0.10 1979.96 2.03 14080753 0.00 0.00 i_free_object
This is not a regression, earlier versions of Ghostsript take a very long time to render this file as well. Acrobat saves the file as a 300 dpi JPEG image in about 10 seconds. Similarly mupdfdraw takes 15 seconds to convert the file to a JPEG (using the command "mupdfdraw -b 0 -r 300 -o AV1205_174_RO.jpg AV1205_174_RO.pdf").
With 9.24 PRE-RELEASE (commit d45ebe70) a 64-bit debug build completes for me in 153 seconds (parse time 42 seconds). This has nbands=8, but uses an unexpectedly large amount of memory during clist rendering, seen by the -Z: output: % Outputpage start time = 41.633, memory allocated = 36888573, used = 16769523, max_used = 42310740 [:]clist_end_page at cfile=107446347, bfile=819968 [:]width=3496, band_width=3496, band_height=323, nbands=8 % Outputpage end time = 152.304, memory allocated = 1171072683, used = 270578435, max_used = 1170433923 Command line arguments used were: -q -sDEVICE=jpeg -dUseTrimBox -r300 -o nul: -Z: AV1205_174_RO.pdf Running in page buffer mode with -dMaxBitmap=1900m the file completes in 42 seconds and only uses 64Mb: % Outputpage start time = 41.168, memory allocated = 58836909, used = 16641386, max_used = 64360804 % Outputpage end time = 41.587, memory allocated = 58904829, used = 16643154, max_used = Running with -dBandHeight=3500, we are still in clist mode, but nbands=1, then the times and memory usage are: % Outputpage start time = 42.007, memory allocated = 70243231, used = 16723166, max_used = 75888654 [:]clist_end_page at cfile=107181361, bfile=800912 [:]width=3496, band_width=3496, band_height=3500, nbands=1 % Outputpage end time = 46.348, memory allocated = 213820173, used = 49052686, max_used = 214148725 Clearly better time, but still 214Mb memory high water mark. This needs investigation, both for performance and memory usage.
Ghostscript is still slow, and it is still spending most of the time in memory management. % cumulative self self total time seconds seconds calls s/call s/call name 44.13 34.02 34.02 1601176857 0.00 0.00 clump_splay_walk_fwd 31.28 58.13 24.11 7088381 0.00 0.00 large_freelist_alloc 3.52 60.84 2.71 17 0.16 4.49 gs_call_interp 2.39 62.68 1.84 65702601 0.00 0.00 dprintf_file_tail 2.24 64.41 1.73 7221226 0.00 0.00 gs_memset 1.80 65.80 1.39 24700628 0.00 0.00 dstack_find_name_by_index 0.92 66.51 0.71 13770767 0.00 0.00 names_ref 0.88 67.19 0.68 41755 0.00 0.00 remove_range_from_freelist
Ad-hoc testing on the current 9.56.0 pre-release code: 32-bit PostScript PDF interpreter 96 seconds, 1.5GB memory 64-bit PostScript PDF interpreter 98 seconds 1.6 GB memory 32-bit C PDF interpreter 7 seconds 16 MB memory 64-bit C PDF interpreter 6 seconds 16 MB memory So using the C based PDF interpreter results in considerable saving in memory and resulting improvement in performance.