Fast Mode UX is Poor

[indolering]

Every recent benchmark of ZSTD that I can find skips "fast mode" (lzbench, squash, peazip, zstd).

This is partly because most of the material about ZSTD was written before the negative ranges were added. People just don't know this and you need to advertise this capability. Maybe you could break your benchmark table and graphs into 3 ranges, like is done here:

The other issue is that users don't read manuals. While I understand hiding the highest compression levels behind --ultra due to spiking client memory consumption, the --fast=[#] is just there to accommodate CLI formatting convention and hides the higher speed levels from end users:

No extra compression settings were used to fine tune the compression, neither for Brotli nor for Zstandard, compression was defined exclusively setting the compression level parameter. Both algorithms features plenty fine-tuning options, which are out of the scope of this benchmark.
-PeaZIP Blog

I would strongly suggest the following:

• Accept negative integers (i.e. --5 and maybe - -5) for the compression level.
• Deprecate (but probably never actually remove) the --fast flag to discourage this being seen as fine tuning.
• Update all documentation to state the full range of levels.
• Highlight the full range on the website and readme.md, perhaps by breaking up the benchmarks into fast, normal, and ultra sections. Make sure to explicitly state the range being from -5 to 22.

[Cyan4973]

We could certainly improve visibility of the --fast mode feature, through a combination of better and more prominent documentation, like the benchmark table.

However, the proposed command line change --5 is problematic, as --anything is a commonly accepted idiom meaning "this is a long command", which purpose is to be descriptive.
- -5 is very different. It currently has the following meaning : "read from stdin and apply level 5". The meaning can't be changed without breaking interface.

With regards to existing restrictions, --fast=# still looks the better option.

[indolering]

However, the proposed command line change --5 is problematic, as --anything is a commonly accepted idiom meaning "this is a long command", which purpose is to be descriptive.

I know, but this is just convention, right? It's not going to break anything or cause Dennis Ritchie to send down lightning bolts or anything 😸.

- -5 is very different. It currently has the following meaning : "read from stdin and apply level 5".

Yeah, that was a stupid suggestion on my part.

[indolering]

I know, but this is just convention, right? It's not going to break anything or cause Dennis Ritchie to send down lightning bolts or anything 😸.

Except it would break -abc. What about a level=[-5, 20] and L=[-5, 20]?

[jhollowe]

I get that the faster versions are considered the "negative" levels, but do they need to be notated as this for the CLI? Maybe a different identifier could be used to denote using a fast level. Maybe #? (i.e. zstd -#2 for zstd --fast=2)

[Cyan4973]

What's wrong with --fast=N ?

[jhollowe]

Mainly, any other functionality that is expecting a level (--adapt, -b and -e, etc) can't use fast speeds.

[Cyan4973]

They can :
zstd -b --fast=3 file
zstd --adapt --fast=3 file

On the other hand, -e is indeed not compatible.

[jhollowe]

But what if I want to limit my adapt to -3 to 3? --adapt-min=-3,max=3 doesn't work (no negative numbers work).

The --fast works for basic functionality, but you can't combine any of the "advanced" features (adapt, fast, ultra, benchmarking, etc) together.

I get that fast is likely to be less used than the normal levels, but allowing for the "negative" levels to be used in all areas would be nice.

[Cyan4973]

It might be possible to add support of negative compression levels for explicit integer parameters such as --long-param=-3.

What's less interesting is specifically the initial --3 proposal, which conflicts with --long-command convention. But this one can still be expressed as --fast=3.