CompressOptions
Defined in: next/api.d.ts:90
The options of compress and compressSync. Other properties
are ignored. F is the formats that the entry point includes: every
Format for @derodero24/comprs/next, and those of one family for
@derodero24/comprs/next/<family>.
Type Parameters
Section titled “Type Parameters”Properties
Section titled “Properties”dictionary?
Section titled “dictionary?”
optionaldictionary?:Dictionary|Input
Defined in: next/api.d.ts:118
A dictionary, for zstd and brotli only: a Dictionary for the format, or the bytes of one, which must not be empty. Decompression needs the same dictionary. A zstd dictionary may be one that trainDictionary trained, or any bytes.
zstd digests the bytes of a dictionary on every call, which costs far more than compressing a small message with it: a Dictionary digests them once.
format
Section titled “format”format:
F
Defined in: next/api.d.ts:92
The format to compress in.
gzipHeader?
Section titled “gzipHeader?”
optionalgzipHeader?:GzipHeaderOptions
Defined in: next/api.d.ts:123
The fields of the gzip header, for gzip only. Without it, or with an empty object, the header has no name and no modification time.
level?
Section titled “level?”
optionallevel?:number
Defined in: next/api.d.ts:107
The compression level, an integer whose range and default depend on the format:
- zstd: -131072 to 22, 3 by default, which 0 also selects. With a Dictionary, the default is the level that it was prepared for, while 0 still selects 3, which a Dictionary prepared for another level digests on its first use, as any other level. Negative levels trade compression ratio for speed;
- gzip, deflate and deflate-raw: 0 (no compression) to 9, 6 by default;
- brotli: 0 to 11 (the quality of brotli), 6 by default.
lz4 takes no level: leave it out.
workers?
Section titled “workers?”
optionalworkers?:number
Defined in: next/api.d.ts:145
The number of threads that compress zstd data besides the calling one: an integer from 0 to 256, 0 by default, which compresses on the calling thread alone. For zstd only, and for the native build only: the browser build accepts 0 alone.
The output can differ from that without workers. zstd compresses inputs
of at most 512 KiB on the calling thread whatever the number, and each
call starts and stops its own workers, so they pay off for large inputs
only. They cost memory too: zstd buffers up to workers + 3 jobs of
the input, gives each job an output buffer of about the same size, and
gives each worker a compression context of its own. With 4 workers at
level 3, where a job is 8 MiB, compressing 96 MiB took about 60 MiB more
memory than without workers for JSON lines, and about 100 MiB more for
random bytes.
compress runs on a thread of the libuv pool, whose size
UV_THREADPOOL_SIZE sets (4 by default), and each call may run
workers threads on top of it: concurrent calls can run up to
UV_THREADPOOL_SIZE * (workers + 1) threads.