[cl-pdf-devel] cl-pdf with salza

[Dmitriy Ivanov]

Hello Zach,

|> One week point: the current version sets the compression level rigidly
|>      (defconstant +zlib-compression-level+ 2),
|> which seems a bit low (for example, GNU ZLIB provides 6 by default).
|> Is there any plans to advance in that direction, Zachary?
|
| The ZLIB data format does not prescribe a compression technique, it
| only describes the resulting output; implementations are free to use
| whatever mechanism they like. The format's "compression level" value
| is purely informational and is not required to have any effect on the
| compressed output.
|
| Salza uses a fixed compression technique right now, so there is no
| flexibility between speed and space. I would like to add this in the
| future.

Thanks for the explanation.

As there are no limits to improve someone else's program, exuse my further
digging :-).

I include di-huffman.lisp in my salza.zip (at lisp.ystok.ru/cl-pdf.html). It
is a rewrite of your huffman.lisp from version 0.4 augmented by Wade's
suggestions on speeding up calls of the write-bits.

Rationale: the distance table is rather huge and should not be included into
the delivered image. Moreover, zlib functionality can even not be claimed by
the application user gestures. So I suggest cretating and populating this
table (actually, the two tables distance-vals and distance-lens) at run time
by invoking the new initialize-huffman function from make-deflate-stream.

With this rewrite, my favorite example exhibits further impovements:

(setq size 100000
      src (make-array size :element-type '(unsigned-byte 8)))
(dotimes (i size) (setf (aref src i) (random 256))))
Timing the evaluation of (PROGN (SETQ V2 (SALZA:COMPRESS-SEQUENCE SRC))
(LENGTH V2))
user time    =      0.093
system time  =      0.000
Elapsed time =   0:00:00
Allocation   = 1614320 bytes standard / 319 bytes conses
--
Sincerely,
Dmitriy Ivanov
lisp.ystok.ru