diff options
| author | B. Watson <urchlay@slackware.uk> | 2025-12-10 16:31:51 -0500 |
|---|---|---|
| committer | B. Watson <urchlay@slackware.uk> | 2025-12-10 16:31:51 -0500 |
| commit | aa01b328ed283ba6247e7c222e67874ca1e5e325 (patch) | |
| tree | 74adf5fe2dde7db31fd8b99b58062c21161ca756 | |
| parent | 9dacd9e8484e1f31828b597deaa6ac0b9836c652 (diff) | |
| download | alftools-aa01b328ed283ba6247e7c222e67874ca1e5e325.tar.gz | |
Tweak alf man page.
| -rw-r--r-- | src/alf.1 | 17 | ||||
| -rw-r--r-- | src/alf.rst | 17 |
2 files changed, 20 insertions, 14 deletions
@@ -247,16 +247,17 @@ compress/decompress such files, and you\(aqd have to have a hard disk and a DOS capable of handling multi\-megabyte files... .SS Performance .sp -Performance is pretty good, as of alftools\-0.3.0. For small files +Performance is pretty good, as of alftools\-0.4.0. For small files like you\(aqd use on an Atari (up to 50KB), it\(aqs basically instantaneous -(0.008 seconds) on the author\(aqs modest i7 workstation. For a 1MB -text file, it takes 0.026 sec; for 1MB of random garbage, it\(aqs 0.043 -sec (and the resulting ALF file is 36% larger than the garbage). +(0.008 seconds) on the author\(aqs modest i7 workstation. For a 1MB text +file, it takes 0.026 sec (faster than \fBarc\fP!). For 1MB of random +garbage, it\(aqs 0.043 sec (and the resulting ALF file is 36% larger than +the garbage). .sp By comparison, \fBzip\fP takes 0.06 seconds to compress the 1MB text file, and 0.03 sec for the 1MB randomness (and the compressed file is still -larger than the input, but only by 312 bytes). The speed demon is \fBarc\fP: -it compresses the text file in 0.03s, and it\(aqs smart enough to \fInot\fP +larger than the input, but only by 312 bytes). \fBarc\fP +compresses the text file in 0.03s, and it\(aqs smart enough to \fInot\fP compress the random garbage (it uses the \(aqstore\(aq method, which \fBalf\fP doesn\(aqt have). .SS Timestamps @@ -268,7 +269,9 @@ options above). There\(aqs no way to store timezone or daylight savings info in the \fIALF\fP file. .sp The year stored in the \fIALF\fP file doesn\(aqt have a Y2K problem. It does, -however, have a Y2108 problem: the range is from 1980 to 2107. +however, have a Y2108 problem: the range is from 1980 to 2107. Files +with timestamps outside this range will have a zero (invalid) date in the +\fIALF\fP header, and \fBunalf\fP will display the date as \fI<none>\fP\&. .sp The timestamp only has 2\-second resolution. Files with odd\-numbered seconds in the \fImtime\fP will have the number before that (1 => 0, 31 => diff --git a/src/alf.rst b/src/alf.rst index 5d6114a..32a2cd3 100644 --- a/src/alf.rst +++ b/src/alf.rst @@ -218,16 +218,17 @@ a DOS capable of handling multi-megabyte files... Performance ----------- -Performance is pretty good, as of alftools-0.3.0. For small files +Performance is pretty good, as of alftools-0.4.0. For small files like you'd use on an Atari (up to 50KB), it's basically instantaneous -(0.008 seconds) on the author's modest i7 workstation. For a 1MB -text file, it takes 0.026 sec; for 1MB of random garbage, it's 0.043 -sec (and the resulting ALF file is 36% larger than the garbage). +(0.008 seconds) on the author's modest i7 workstation. For a 1MB text +file, it takes 0.026 sec (faster than **arc**\!). For 1MB of random +garbage, it's 0.043 sec (and the resulting ALF file is 36% larger than +the garbage). By comparison, **zip** takes 0.06 seconds to compress the 1MB text file, and 0.03 sec for the 1MB randomness (and the compressed file is still -larger than the input, but only by 312 bytes). The speed demon is **arc**\: -it compresses the text file in 0.03s, and it's smart enough to *not* +larger than the input, but only by 312 bytes). **arc** +compresses the text file in 0.03s, and it's smart enough to *not* compress the random garbage (it uses the 'store' method, which **alf** doesn't have). @@ -241,7 +242,9 @@ options above). There's no way to store timezone or daylight savings info in the *ALF* file. The year stored in the *ALF* file doesn't have a Y2K problem. It does, -however, have a Y2108 problem: the range is from 1980 to 2107. +however, have a Y2108 problem: the range is from 1980 to 2107. Files +with timestamps outside this range will have a zero (invalid) date in the +*ALF* header, and **unalf** will display the date as *<none>*. The timestamp only has 2-second resolution. Files with odd-numbered seconds in the *mtime* will have the number before that (1 => 0, 31 => |
