Created attachment 6583 [details] compress xl testfile with low performance at 600dpi printing attached xl-testfile (VZXP9TJ2.xl) is extremely slow at 600dpi (2 pages take > 15 minutes). This is much slower than our other PDL-implementation. on CYGWIN (default build: make pcl) time obj/pcl6 -r### -sDEVICE=bit -sOutputFile=/dev/null -dNOPAUSE VZXP9TJ2.xl ### = default = 72dpi memory 72dpi: 0m33 14.8Mb used 100dpi: 0m52 15.0Mb used 150dpi: 1m33 15.6Mb used 200dpi: 1m30 17.6Mb used 250dpi: 1m37 17.6Mb used 275dpi: 1m30 19.7Mb used 287dpi: 1m33 19.2Mb used 295dpi: 1m37 19.8Mb used 298dpi: 1m40 18.8Mb used 299dpi: 8m53 70.3Mb used 300dpi: 8m36 !!! 71.3Mb used 400dpi: 12m53 72.2Mb used 600dpi: 19m21 74.4Mb used there is a huge jump in performance-regression between 298dpi and 299dpi, after that it seems more-or-less linear (with resolution) again. for the JPEG device the time for 600dpi is just 11 secs!!! First analysis gives following callback-stack (see attachment callback)
Created attachment 6584 [details] callback_stack callback stack during processing of xl-job
pinned it down to gxpcmap.c switching to a clist for patterns. Enlarging the MAX_BITMAP_PATTERN_SIZE to 5MB, gives the following result: time: 1m45 mem: 31.5MB So clists for patterns seems inherently slow. Perhaps you could do some thinking on this. Comments in gxpcmap.c only refer to PDF/PS but PCL-XL also uses this path.
Ray was having a look at this, I'll talk to him about it Monday. Thanks Norbert.
Actually, what I was looking at was unrelated to a 1-bit monochrome device (bit device). There was a bug in the logic that determined the pattern bitmap size because the PaintType == 1 was used to force the depth to 1, but it should be PaintType == 2 since that is an uncolored pattern (mask). For bit devices, the pattern size is the same since the tdev->color_info.depth is also 1. As far as the default size for a MAX_BITMAP_PATTERN_SIZE I don't have any problems with setting it to a larger value. The one issue to be aware of is that the pattern_cache is set for 50 slots by default, and if each of these is a different pattern bitmap, each can be up to the MAX size ! To handle the (unexpected) case where there are many patterns, all with large size, I am thinking that we need to base the decision not only on the MAX_BITMAP_PATTERN_SIZE, but also on the total pattern_cache allocation for all of the bitmaps. I will work on this, but since this is an unexpected condition, just increasing the current fixed limit is not a bad approach.
I changed the default threshold for pattern bitmaps to 8*1024*1024 (8Mb) in rev 11605 and added a new paramter -dMaxPatternBitmap=# to allow this to be set using the command line, or as a device parameter (e.g. setpagedevice). I also added documentation in rev 11611 to doc/Use.htm Command line device parameters can be used with ghostscript (gs, gswin32c) as well as with the GhostPDL parsers that use plmain (gxps, pcl6, pspcl6, etc.) Now that it is not a compile time option, closing this bug. Thanks to Norbert for finding the root cause of the performance problem.
Changing customer bugs that have been resolved more than a year ago to closed.